Our modern identity services are exposed through developer-friendly APIs, SDKs and Low-Code services to deliver the scale and performance required for any and all customer use cases.
Featured Blog Post:
It’s notoriously difficult to implement an account recovery process that prevents fraud without creating more friction for customers who are already locked out and frustrated. In a US consumer...
While the rapidly growing use of APIs has provided a way for enterprises to quickly launch new applications and features, they also present a daunting challenge: protecting both customer interactions and programmable API interfaces from an ever-expanding array of threats. To protect against these threats, teams must have an understanding of the identity context of the users making requests to understand if they are legitimate or malicious.
However, gaining this crucial context is often complicated by the fact that API security and fraud detection are typically thought of as two separate jobs to be done, to be handled by separate teams and separate solutions. This disjointed approach comes at a great cost for identity and security leaders alike, exacerbating resource constraints, prolonging time to mitigation and resulting in security blind spots. Fortunately, solutions that take a consolidated, identity-first approach to these threats provide a way to overcome these challenges.
In this blog, we’ll help identity and security leaders understand the need for identity context in API security and fraud detection, the overlap between fraud and API-based attacks and why a consolidated approach is needed to mitigate today’s most pressing threats to application security.
As we outlined in our previous blog in our API security series, securing APIs presents a host of challenges, including the difficulty of discovery, the ease of launching sophisticated attacks and the complexity of access control. In the face of these challenges, traditional API security solutions that limit protection to detection based on static rule sets only cover a fraction of what’s needed for robust API protection.
To fortify protection and ensure rules stay relevant in the face of evolving threats, security teams must devote constant attention to updating rule sets and correlating intelligence on known malicious behavior from other solutions that can help assess whether API requests are legitimate or fraudulent.
Similarly, fraud detection solutions often rely on static rule sets and fragmented risk signals from separate point solutions, which must be correlated and standardized in order to gain the identity context needed to assess whether the user is fraudulent or legitimate. To accomplish this difficult task, teams often rely on a complex web of heuristic rule sets or black-box AI solutions that do not provide adequate visibility into their decisioning logic.
Without the ability to analyze and correlate users and their current and historical behavior across all application transactions, teams struggle to detect anomalies in
both API and end-user interactions that can lead to fraud and are forced to respond reactively — rather than proactively — to new attack MOs (modus operandi).
And, as we’ll see in the next section, these evolving threats increasingly span the realms of both API and end-user security, resulting in challenges for enterprises that use separate solutions and separate teams to mitigate fraud and API attacks.
Because APIs can be difficult to discover — let alone protect — they often contain vulnerabilities that provide an entry point for threat actors seeking to gain access to user accounts and sensitive data. In 2022, vulnerabilities in APIs, which offer a treasure trove of data, were the root cause of over half of all data breaches, providing attackers with information that can be used for account takeover (ATO) and fraudulent transactions.
Conversely, many API vulnerabilities — including several of the top OWASP threats — are related to insecure authentication and authorization practices, making the detection of identity-related risk signals during API requests a crucial capacity for securing APIs. As a result, investigating and mitigating API attacks and fraud separately prevents teams from understanding the root cause of these threats — leading to a host of challenges that we’ll address in the next section.
When separate solutions are employed to protect against fraud and API attacks, two distinct teams must collaborate on mitigation efforts, hindering the correlation of information crucial for expediting threat mitigation.
To illustrate how this challenge can increase time to mitigation and weaken security consider two examples of threats that span both API and client-side security:
Moreover, as attackers become increasingly adept at scaling attacks and evolving their tactics, the potential losses suffered as a result of slow mitigation can be devastating.
As shown above, the use of separate vendors for fraud detection and API security can result in siloed risk signals and missed connections between related incidents, leading to security blind spots. These blind spots not only delay and hinder mitigation of threats, but make it difficult to prioritize incidents and complicate fraud operations that require rigorous investigation and reporting.
In addition, API security incidents may lead to an avalanche of fraudulent activity related to the vulnerability, overwhelming fraud teams with alerts and making it difficult to prioritize and respond to the most critical threats. The absence of consolidated reporting and a lack of visibility into API vulnerabilities can also hinder fraud analysts from creating a comprehensive incident timeline, hindering post-incident analysis that is needed to protect against future attacks.
The tech industry’s talent shortages and the need to reduce costs across the board have left enterprises with diminished budgets and fewer skilled professionals to investigate and mitigate security threats. This scarcity poses a challenge for teams that must purchase multiple solutions and devote expertise and man hours to deploy, manage, and maintain them.
And because these solutions are typically owned by two separate teams, with fraud teams managing fraud detection tools and cybersecurity teams managing API security tools, resources are further strained due to duplicated efforts in investigating incidents that span both fraud detection and API security.
In addition, each new solution requires new and upskilled team members to be trained on how to operate it and increases the complexity of integrating and standardizing risk signals. This demands time and expertise that are often hard to come by, reducing the resources teams can devote to addressing new and ongoing threats.
By taking an identity-first approach that consolidates fraud detection solutions with API security solutions, organizations gain improved context that can help teams reduce security blind spots, accelerate vulnerability identification, and enhance their understanding of necessary protections against emerging threats.
AI-based solutions can provide this crucial context by recognizing patterns of behavior in customer interactions, data transmission via API and API call sequences and detecting anomalies in each user’s typical behavior in accessing both customer accounts and APIs. This not only enables more robust, real-time protection that proactively identifies suspicious requests, but helps teams gain the unified visibility they need to pinpoint the root cause of emerging threats and quickly address them.
These capabilities are foundational to Transmit Security’s approach to customer identity security, which is underpinned by AI-based detection and response services that enable enterprises to better contextualize user requests and respond to risk and trust signals.
Identity orchestration capabilities can be further used to assist with consolidation, as it enables the correlation of API and end-user risk signals and can help teams standardize and harmonize data from multiple solutions to improve how fraud detection and API security solutions work together to simplify multi-vendor management of different point solutions.
Stay tuned for the final blog in this series, where we’ll explain how this unique approach to identity-first security can strengthen API security and how enterprises can benefit from it.
