API insecurity is responsible for between 4.1% and 7.5% of cybersecurity incidents, according to a new study.
The study, conducted by the Marsh McLennan Cyber Risk Analytics Center and based on an analysis of nearly 117,000 unique cybersecurity incidents, found that larger organizations were statistically more likely to have a greater preponderance of API-related incidents.
Large enterprises were three to four times more likely to experience API insecurity than small or midsize businesses.
The accelerating pace of digital transformation and business development leaves large enterprises more at risk from exposed or unprotected APIs, according to Imperva, the cybersecurity vendor sponsoring the research.
APIs (application programming interfaces) are a class of software technology that offer a bridge to enable applications to access data or hook up with external software components, operating systems, or microservices.
Many APIs connect directly to backend databases where sensitive data is stored, a feature that attackers have latched onto resulting in an increase of attacks targeting what have become building blocks of modern online services.
APIs enable damaging attacks, from DDoS attacks taking a service out of commission to manipulator-in-the-middle attacks to intercept, steal, and modify or redirect communications, to injecting malicious code, taking over services or accounts, or simply stealing from the vast databases that many APIs connect to.
“As many as one in every 13 cyber incidents can be attributed to API insecurity,” according to Imperva. “As the number of APIs in production multiplies, this figure is expected to grow in the coming years.”
Scale up
Imperva told The Daily Swig that larger organizations are particularly exposed to the issue because they have “more APIs and limited visibility leaves a larger number of APIs vulnerable”.
Lebin Cheng, vice president of API security at Imperva, commented: “The growing security risks associated with APIs correlate with the proliferation of APIs, combined with the lack of visibility that organizations have into these ecosystems. At the same time, since every API is unique, every incident will have a different attack pattern. A traditional approach to security where one simple patch addresses all vulnerabilities doesn’t work with APIs.”
Cheng added: “The proliferation of APIs, combined with the lack of visibility into these ecosystems, creates opportunities for massive, and costly, data leakage.”
Running the numbers
Imperva’s study found a wide disparity in the extent to which different industries are exposed to API security-related issues.
For example, in the information technology industry the estimated percentage of incidents caused by API insecurity was between 18% and 23%.
By the same metric, professional services were also highly exposed to API-related problems (10%-15%) while manufacturing, transportation, and utilities (all 4-6%) are all in the mid-range. Industries such as healthcare have less than 1% of security incidents attributable to API-related security problems.
Many organizations are failing to protect their APIs because it requires equal participation from the security and development teams, which have historically have been somewhat at odds.
Cheng told The Daily Swig: “Developers move quickly and modify APIs constantly, making it nearly impossible for security teams to keep up. It means that many have defaulted to relying on ineffective tools because they hope a standardized approach can minimize threats.
“However, these defenses aren’t equipped to stop sophisticated API-related attacks targeting business logic vulnerabilities.”
“APIs are created and managed by the development team, often outside of the security team’s purview. Complicating matters, each API is designed for a specific application’s needs,” they concluded.
The Imperva-commissioned report, entitled Quantifying the Cost of API Insecurity, concludes with advice in getting a handle on the problem. This includes identifying and classifying data flowing through every API, automating discovery of APIs, and enabling an API governance model.