Getty Images
API management: Assessing reliability and security
Once an API is published, its developer then has responsibility to ensure it is kept up to date and is secure
Application programming interfaces (APIs) have had their status upgraded from the domain of programming tool to the proverbial icing on the cake to top a digitisation business plan. APIs allow business leaders to enable workflows across organisational boundaries, connecting siloed business systems and providing a controlled way for external business partners to access data and services.
The API, and the code accessed via the API, must be secure. Any vulnerabilities need to be fixed as soon as they are discovered; otherwise, any application accessing the API will inherit this security weakness.
In the open source world, GitHub recently introduced an automated alert mechanism to enable developers to address vulnerabilities in the open source components their code uses. Such mechanisms enable consumers of these components to receive an alert if the component has a security risk and needs patching or a workaround. This is essential if organisations require end-to-end auditability covering a software bill of materials for all the software components used in a finished product.
Tackling API security is a subset of software development that is secure by design, where there are strong processes in place to minimise coding errors that lead to vulnerabilities, and a defined pipeline to resolve security issues quickly. But the pace of software development – and that includes developing and modifying code that is accessed via published APIs – can lead to insecure code slipping into production systems.
In April 2022, Dynatrace commissioned Coleman Parkes to run a global survey of 1,300 CISOs in large organisations with more than 1,000 employees, which highlighted the risks organisations face in code development and deployment. The survey found that two-thirds (67%) of CISOs say developers do not always have time to scan for vulnerabilities in their code and apply a fix before it moves into production. Only 27% of the CISOs surveyed say they are fully confident that applications have been fully tested for vulnerabilities before going live in production.
Discussing the findings, Bernd Greifeneder, chief technology officer at Dynatrace, says: “There are always opportunities for vulnerabilities to slip past security teams, regardless of how robust their defences might be. Both new applications and stable legacy software are prone to vulnerabilities that are more reliably detected in production.”
A DevSecOps approach
One area that should be considered both from the development of APIs and those developers who consume APIs in their own applications, is the security implications. Is the code secure? Is the API safe? Can the API provide hackers with a backdoor into corporate systems?
DevSecOps plays an important role in ensuring security remains a top priority in any software project.
Dynatrace’s global study of 1,300 CISOs reported that just over one-third (34%) of organisations have a mature DevSecOps culture, where the majority of teams have integrated security practices across the software development lifecycle.
Describing a simple three-step flow of code-build-deploy, Alejandro Bernal, a security architect and member of ISACA’s Emerging Trends Working Group, says DevSecOps is usually attached only in the coding step. But each step has its own challenges. Starting with source code management (SCM), Bernal says software developers need to ask: “Do we know how many vulnerabilities our source repo has? Can we track each one of them back to its source package? How do we control/monitor them?”
These are some of the questions that pop up in the coding stage.
This is the domain of static application security testing.
The next phase – build – requires software developers to pull in external components or artefacts from external code repositories. Modern, cloud-native practices often mean that these artefacts are containerised. Bernal says developers need to ensure that the security status associated with these code artefacts meets the same criteria set for the code developed internally.
“If some risk acceptance took place – for example, a package with no available fix but which is imperative for the application to work – or all vulnerabilities have been remediated, the artefact should remain with the same [security] status,” he says. “Is there any way to know if something bad made its way to the container image?”
Irrespective of the software architecture used, the final phase – deployment – involves what Bernal describes as “a proper toolchain” aligned to this architecture.
Vulnerabilities need to be fixed quickly, but developers also need to keep their code up to date to take advantage of the latest and greatest technology or to support new requirements from the business. Among the difficulties is that as functionality accessed via the API changes, the actual API may require changing because the data it requires (ie, the parameters a programmer needs to provide to the API) and the data it returns back to the application accessing it, may need to be adapted in line with the new functionality.
The challenge for the API developer is that any changes can potentially break any application that uses the API.
Software development teams may often not take care to support the backward compatibility of APIs, warns Stephen Feloney, vice-president of products, continuous testing at Perforce. “An API that previously worked may not work as it should in an updated or completely new version,” he says.
With each new version of an API, additional parameters may be required, results may be delivered in different formats, and even when developers maintain backward compatibility, old APIs may continue to work, but only for a limited time, says Feloney, adding: “Teams consuming APIs may be unaware of the new changes to the APIs until a sudden failure occurs.”
If this happens, says Feloney, software development teams need to track the failure to its source to find the root cause of the problem and verify that documentation is up to date, which can be a time-consuming and costly process. The same applies when a component that the API relies upon is updated. Teams avoid unexpected API failures if they track code dependencies and API changes, says Feloney.
API security implications
When it ran a survey of 350 of its customers, Salt Security found that the average number of APIs per customer had grown by 82% over past year, up from 89 in July 2021 to 162 in July 2022. During the same period, overall API traffic per customer grew by 168%, indicating that API usage is also exploding.
Worryingly, attack activity has continued to keep pace with this dramatic API usage growth and now accounts for 2.1% of overall API traffic for Salt Security customers. Its survey also found that malicious API attack traffic surged by 117% over the past year, from an average of 12.22 million malicious calls per month to an average of 26.46 million calls.
More than half (54%) of respondents admitted they have had to slow the roll-out of a new application because of an API security concern. Also, the increasing regulatory focus on sensitive data leaks is impacting profitability, and the public is taking notice. In fact, nearly one-third of respondents admit they have experienced sensitive data exposure or a privacy incident within their production APIs over the past year – a sharp increase from last year’s 19%.
Commenting on the findings, Nick Rago, field CTO at Salt Security, says: “Many API attacks today are done by authenticated entities that have authority to use the API they are attacking and are doing it in a low and slow manner that evades any rate limit traffic controls.”
According to Rago, existing security measures employed by API gateways, web application firewalls and identity providers fail to offer adequate protection against this growing attack surface. “To stop attacks, organisations need a security strategy specifically designed for APIs,” he says.
Key capabilities of such a security strategy should include continuous visibility into the attack surface, as well as the ability to discover new and changed APIs, contextually understand API behaviours to accurately detect and stop API attacks and abuse in runtime, and remediate vulnerabilities in the build phase.
Most organisations have now caught the wave of using APIs to provide flexible connectivity between systems, making it easy for developers to get started and build digital products. But securing and monitoring APIs is a crucial step to operationalising APIs.
Brian Otten, vice-president of the digital transformation catalysts division at Axway, also believes that businesses need to manage the lifecycle of their APIs. “API delivery has a distinct lifecycle that includes, but is not limited to, unified monitoring of APIs from a security, availability and performance perspective,” he says. “Also, capabilities focused on cataloguing and managing APIs on a day-to-day basis alongside controls related to standards, governance and testing.”
