Over the last decade the growth of APIs has skyrocketed which has produced fertile grounds for bad actors looking to exploit them. Poorly designed APIs represent significant risk to the organization if they cannot be identified and corrected quickly. API security platforms have started to gain traction as they offer methods to identify APIs that use the Open API specification. They can evaluate the structure of these APIs against a list of known issues (OWASP) to determine potential risks in their design.
However, these platforms are not foolproof and they largely ignore the root cause of the problem. What is needed is a collaborative, process-driven, approach that can bring together the teams that produce the APIs and the the cyber teams responsible for protecting them.
Introduction
As the use of the Application Programming Interface (API) grows so does the opportunity for bad actors to abuse them. There have been many stories of hackers taking advantage of poorly designed APIs to steal information or hold organizations for ransom.
Recently, T-Mobile had its 5th major data breach in just 5 years when a bad actor accessed a poorly designed API and used it to steal 37 million customer records. Although it is unlikely that T-Mobile will share exactly how the API was abused, it is safe to say that the root cause was the design of the API itself coupled with a lack of proper oversight.
It is also very likely that after the previous data breaches, T-Mobile increased its cybersecurity budgets and took radical steps to protect its infrastructure. Despite this investment, a 5th breach still occurred. Why weren't the flaws in this API discovered by this investment?
The reason lies in the seismic gap that exists between the teams that write the APIs and the cybersecurity teams that are charged with defending the organization from cyber threat. It can be safe to say that neither of these teams collaborate as much as they should. Beyond surface level policy definition, chances are these teams do not collaborate at all. Hackers are now exploiting this. They know that API development is on the rise. They know how APIs work and they know that API code can be pushed to production with security flaws. They also know that this process doesn’t appear on the radar of the cybersecurity teams.
The API/Cyber Gap
Traditionally, cybersecurity efforts have been laser focused on perimeter defense. These groups invest heavily in keeping the bad guys out. They have also invested in tools that sniff out anomalous web traffic. For example, if a port on a server is being hammered by a potential brute force attack, they can be alerted to this unusual behavior and take appropriate steps to address it. The tools and platforms used by the cyber teams are geared to support this effort.
But hackers know this and are becoming more and more sophisticated. Once a gap is found they often sit and wait and very carefully begin to expand their capabilities. They do this by looking for internal APIs that are left unprotected. The unprotected API represents a huge gap in the cyber defense and the cyber security teams are almost completely powerless to defend against the abuse of a poorly designed API.
The Rise of the API Security Platform
Recently, the software industry has begun to focus on this issue and security platforms designed to track and catalog APIs have begun to appear. These platforms are somewhat similar in that they attempt to:
Identify the presence of an API
Analyze the API against security standards (OWASP)
Implement proxies, gateways and agents to track API usage
These capabilities are critical in reducing the risks associated with organizations that develop and host APIs both internally and externally. If you ask security officials how many APIs they have in production, they will likely have no clue. By identifying and cataloging APIs they can answer this question with greater accuracy.
API security platforms play a critical role in that their implementation helps to increase control, transparency and consistency.
However, API security platforms are not 100% foolproof and worse yet, they largely ignore the root cause of the problem. They attempt to identify problems solely using a technical, AI-driven approach whereas a process-driven, collaborative approach is also required.
Cyber gaps inherent within API Security Platforms:
They do not address the root cause
They do not address design or quality issues found within each API
They struggle to identify dark APIs (APIs that are published but seldom used)
They struggle with legacy APIs not documented or deployed on a gateway
They do little to track the progress of remediation efforts
Examples of API Security Platforms: Mulesoft, Axway, Salt Security, Traceable, IBM API Connect, Google Apigee, Amazon API Gateway, Azure API Management
The Likely Root Cause of the T-Mobile Data Breach
At some point a developer published a poorly designed API to a server which exposed it to other systems within the T-Mobile infrastructure. This API could have been governed by an API gateway and tracked within an API Security Platform yet neither of these technologies would have known about the design flaws contained in the API itself. A hacker using a Phishing technique may have been able to access internal networks and learn about the internal API landscape. Using simple tests and with their knowledge about how APIs and applications work, they silently found the flaw that would lead them to the source of data itself.
How Collaboration Can Solve This Problem
Organizations should assume that this scenario is already taking place. They should also assume that there is API code that exists which is poorly designed and easily exploited. Given the gaps in the security platforms, to stand the best chances of solving this challenge requires collaboration between the cyber and product teams.
Collaboration comes in the form of a coordinated, program-approach requiring people, process and technology to identify root causes and implement the appropriate processes to solve this challenge. This approach requires executive oversight and sponsorship since it straddles two different teams. It also requires a central platform that can accept data from internal systems and capture feedback from developers and other stakeholders. Check out www.reactfirst.io as a prime example of such a platform.
With such a platform and capability, the organization can then conduct these four critical steps to have the best chance of solving this problem:
Step One: Implement a set of design standards for API developers using the “Shift-Left” mindset. The idea is that developers will begin to produce higher quality and more secure code. This effort will begin to correct the root cause of the problem but even with the strictest standards in place, developers still cut corners and so a periodic API quality and risk audit is also important.
Step Two: Conduct a developer survey. By far the best way to understand the existence of dark APIs is to simply survey the development teams. They will often provide the best clues into the use of hidden or homegrown gateways, internal middleware components and other technologies which can keep an API off the cyber team’s radar.
Step Three: Conduct a thorough audit of each API in order to understand the state of the API from a risk and quality perspective. It is via this effort that the design and exploitability of each AP can be better understood. The audit will combine feedback from developer surveys and data inputs from API security systems, gateways and other platforms that capture API-related information. The combined perspective should then be passed through a rubric so that standardized risk and quality scores can be assigned to each API. With a set of standard results, the organization would then be in a position to prioritize the remediation of high-risk APIs.
Step Four: Track the remediation effort via executive stakeholder dashboards and via key remediation metrics and milestones. Given that changes to an API can have upstream and downstream impacts, the remediation effort needs to be planned and tracked carefully as this effort can sometimes span weeks or months. In addition, this work tends to compete with other development efforts and therefore runs the risk of being pushed to the bottom of the development team’s backlogs. By tracking against a plan, stakeholders can determine if these efforts are at risk of missing deadlines.
Summary
By implementing a collaborative process and combining data from multiple systems, the organization can create the most accurate and complete representation of their APIs. With this oversight, the organization can then take steps to solve the root causes of poorly designed APIs and collect the data needed to track the efforts required to remediate this problem.
API security solutions help organizations build a catalog of APIs but they do little to understand the quality or risk these APIs expose. These solutions also do little to track remediation efforts against executive goals, nor do they manage the collaboration required to implement a comprehensive solution.
To achieve success requires the intersection of people, process and technology in a collaborative effort across product teams (developers) and the cybersecurity teams.