By Dylan D’Silva
First, let’s define what an API is for those unfamiliar with the term and the technical concept, since there are more acronyms in IT and Cybersecurity than you can shake a stick at. API is short for Application Programming Interface, which allows two software programs to communicate with each other. APIs authorize and grant access to data and services that are requested by other applications or users.
There are several reasons for businesses to leverage APIs, least among them being to manage how users and systems get access to services and data through controlled security, as well as allow other organizations to use their data to integrate. Here is what you may not realize. APIs are so critical to our digital world and operate so many aspects of our lives, so seamlessly and transparently, that we don’t pay any attention to it or give it a second thought because of the implicit trust we have placed in devices, software and applications that run our lives 24x7x365. Retail, banks, technology, transportation, to critical infrastructure and about everywhere in between all leverage APIs in some way. APIs are a double-edged sword in that they enable so much functionality, but also expose application logic and sensitive data, as OWASP points out. I highlight this because with the trust and credence we give the technology in our lives, and by extension the APIs that help operate it, it’s important we focus on API Security.
API Security is an important topic to discuss, so much so that OWASP (the Open Web Application Security Project), authored an API Security Project and published a Top 10 list of common flaws in 2019 (more on that a bit later).
In addition to the API security trends published in the 2022 State of API Security report, Michelle McLean at Salt Security has done a phenomenal job in detailing what API Security is all about and why it’s important. “As the attack surface has grown, and as more bad actors have realized how lucrative it is to target APIs, the number of API attacks has skyrocketed. That same research report shows that 95% of companies had an API security incident in the last 12 months, API attack traffic grew by 681% while overall API traffic grew 321%.”
Michelle highlights the following as to why API Security is different than securing traditional IT Infrastructure as they offer unique challenges:
“A constantly changing landscape: Given the pace of development, it’s nearly impossible to stay up to date on new and changed APIs. Documentation is always incomplete and often out of date.
Low-and-slow attacks: Traditional attacks, like SQL injections or cross-site scripting, still happen, but the successful API attacks don’t follow those kinds of “one-and-done” mechanisms that leverage known vulnerabilities. Every API is unique, so every attack has to be unique, as bad actors probe the APIs for business logic gaps they can exploit.
The shortcomings of shift-left tactics: Standard pre-production testing can find some gaps in API security best practices, but they won’t uncover vulnerabilities rooted in API business logic gaps. And no developer writes fully secure code every time.”
Now that we understand what an API is, how critical they are to our everyday lives, the importance of API security, and some challenges that come with securing them properly, let’s come back to OWASP’s Top 10 list of API Security:
- BOLA – Broken Object Level Authentication
- Broken User Authentication
- Excessive Data Exposure
- Lack of Resources and Rate Limiting
- Broken Function Authorization
- Mass Assignment
- Security Misconfiguration
- Improper Assets Management
- Insufficient Logging and Monitoring
These threats are listed in order of frequency, so the last one, “Insufficient Logging and Monitoring,” is not the highest priority. However, it’s worth sharing some insights into what’s needed in this area.
Per OWASP, “insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring”
No security professional worth their salt would be satisfied with a “one-and-done” scenario, meaning you don’t just deploy a product, or in our case, an API that the development team built and consider it finished. If you don’t know what you have, how can you confidently expect to protect and defend it? If you have insufficient logging and monitoring, or worse, none, how can you tell what’s happening with that API?
With various sources coming to a similar conclusion, that on average, it takes 200 days to detect a breach. For perspective and context, if the intrusion and breach started on January 1st, 2022, it would not be detected until July 20th 2022.
How can you tell if an API is vulnerable? Directly from OWASP’s Github repo, there are a few things to consider when evaluating threat agents/attack vectors, security weaknesses , and impacts:
- Attackers take advantage of lack of logging and monitoring to abuse systems without being noticed.
- Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities and respond to them in a timely fashion.
- Without visibility over on-going malicious activities, attackers have plenty of time to fully compromise systems.
Also, per the GitHub repo, an API can be considered vulnerable if:
- It does not produce any logs, the logging level is not set correctly, or log messages do not include enough detail.
- Log integrity is not guaranteed (e.g., Log Injection).
- Logs are not continuously monitored.
- API infrastructure is not continuously monitored.
Why should anyone care about Logging and Monitoring in the context of API Security? Application and Monitoring logs are invariably a gold mine of data which will help:
- Identifying security incidents
- Monitoring policy violations
- Establishing baselines
- Assisting non-repudiation controls (note that the trait non-repudiation is hard to achieve for logs because their trustworthiness is often just based on the logging party being audited properly while mechanisms like digital signatures are hard to utilize here)
- Providing information about problems and unusual conditions
- Contributing additional application-specific data for incident investigation which is lacking in other log sources
- Helping defend against vulnerability identification and exploitation through attack detection
With the average total cost of a breach in 2021 being $4.24M USD, plus the reputational harm inflicted by a breach, the effort required to implement Logging and Monitoring for APIs pales in comparison. Simply imagine the scenario of yourself as the cybersecurity leader within your organization needing to communicate to your leadership team that because we didn’t implement proper monitoring and logging for APIs (amongst other things) that it’s going to cost upwards of $4M to resolve. If that scenario alone does not get you to rethink, re-evaluate and validate what strategies and tools you have in place today, as well as ensure they are sufficient, then I don’t know what will.
About Dylan D’Silva
A curious person by nature with a love for technology and formal education in system administration and networking, Dylan brings 15+ years of IT, Project Management, and Technology Delivery experience from deep experiences in telecom, higher education, food & hospitality, e-commerce and finally vulnerability management within Cybersecurity.
With a career shift into Cybersecurity, he continues to build expertise in Cloud, Pentesting, Vulnerability Management, and Programming Languages with the hope to complete a Full-Stack Engineer course in the not-so-distant future. An additional aspect Dylan likes to focus on, is how companies are developing and bench-marking their cybersecurity strategies, policies and posture, and when breaches, attacks, and ransomware occur how they go about responding.