An Application Programming Interface (API) is the connective tissue of the digital ecosystem, It allows software applications to interact with each other. It is as much a part of modern software technology as microservices architectures.
The popularity of API use, however, has also spawned misuse and in some cases a failure to follow best practices. This has led to APIs becoming a new vulnerability vector.
According to the VMware Global Incident Response Threat Report 2022, 23% of respondents to the survey pointed to APIs as a new vector of attack. The top types of API attacks include data exposure (encountered by 42% of respondents in the past year), SQL and API injection attacks (37% and 34%, respectively), and distributed denial-of-service attacks (33%).
These findings suggest attackers are not only seeking to compromise API security as an end but are leveraging it to distribute additional, often destructive attacks, also known as progressive API attacks.
According to Rick McElroy, principal cybersecurity strategist at VMware, traditionally adversaries went after things like endpoints and servers and laptops and tried to fool users by getting to click on things or even hold them for ransom and steal their data.
“What we've seen over the last few years is a pivot towards the attackers going after APIs. Now, this is important because APIs underpin almost everything we do, from a technology perspective – from disaster recovery to datacentre orchestration to security instrumentation and automation as well.”
Rick McElroy
“It's all facilitated via APIs, hence the massive vulnerability,” he continued.
As an endpoint, does this not make APIs also a new vector to attack?
Rick McElroy: Absolutely. Much like other technology that is also under attack, we need to ensure that we have a good understanding of what APIs-based attacks look like.
To be on the path to improved security, organisations need to conduct regular API assessments and implement meticulous detection of API-based attacks which attempt to go after their infrastructure to carry out nefarious activities.
Lastly, organisations should be well equipped to be able to respond in real-time to such attacks.
Which API practices present the most acute areas of security risk? [BOLA, BFLA, excessive data exposure, etc)
Rick McElroy: I think one of the areas that we see in the cybersecurity industry being continually exploited is just a lack of authentication or strong rotation of cryptographic keys over those APIs. So, we've implemented APIs, which is fantastic.
However, the security that underpins though, is the ability for one machine to make a call to another machine to get data back or for some type of injection of data. Generally, the authentication around that isn't where it needs to be.
I think, going through your code repositories, and being able to scan them and try to understand the credentialing that occurs to make those debit API calls needs to be put in place.
How then can enterprises enhance their approach to API use while containing any potential threat that may come because of the use of API?
Rick McElroy: Just like any other area of technology, they need to consider that it's a program that needs to be managed. And that should start with the assessment phase, getting visibility into the types of API calls that are deployed to gain visibility into the custom code that security or developer teams have developed, which have APIs already enabled.
I’ve come across a lot of cases, wherein teams that are doing these API assessments have the code repositories scanned, and they have five versions of the same API, but only one is in use. So, it's crucial to fill out that attack surface a little bit as well as to the assessment processes.
Given that one of the rationales for using API is to enable faster time-to-market without altering core legacy systems, name three API security strategies that would improve API performance.
Rick McElroy: The first and foremost strategy I would suggest is for organisations to implement an API gateway which will allow you to authenticate traffic and provide other necessary functions such as monitoring, analytics, and alerts on how your APIs are being used.
Secondarily, I would say you absolutely need a network component to look at specific behaviours on the network and what the adversaries are doing to attack these APIs.
And finally, I think some of the more forward-thinking technologies that are out there and the strategies around securing APIs are really doing attack simulations against them today, to move towards a place where they can be future-proofed.
I do like that model of continually assessing and doing adversary emulation against the APIs as well.
Briefly, the other threat vector is containers. What can and should be done to curtail threats arising from the use of containers?
Rick McElroy: I think there are a few misnomers that we see a lot when it comes to the security of containers such as legacy architecture servers that have been living for 10 years inside of a data centre.
I assure you that the adversaries have barely adapted to what we're doing with containers. Typically, we've seen them develop several custom remote access tools for the Linux platforms that enable content and allow organisations to be able to update, patch and understand the behaviours of those containers so that you can better prevent, detect, and respond to the challenges presented using containers.
In summary, what is your recommendation for CISOs/CIOs in their digital journey?
Rick McElroy: Well, number one, I would say this is where all security strategies should meet. I think it's incorrect and probably will yield little security fruit, to have a CIO dare make decisions that are disjoint, from what security can do.
But I think if we start to consider shared models and shared culture among teams and bring them together, security strategies can be delivered and help do things like heal itself, when you must patch it, to be able to provide better detections and among many things.
It really takes a combined effort to create collaborative cultures among the two groups. And for me, it really starts at the top, so, I think the CIO and CISOs should have a shared strategic plan and vision.
