This research note is restricted to the personal use of [email protected].

Protecting Web Applications and APIs From Exploits and Abuse

Published: 24 April 2019 ID: G00383318

Analyst(s): Frank Catucci, Michael Isbitski, Ramon Krikken

Web applications, mobile applications and web APIs are subject to increasing volumes and complexity of attacks. Security and risk management technical professionals responsible for application security architecture must use an appropriate mix of mitigating technologies to secure applications.

Key Findings ■ Automated attack and abuse patterns have evolved, making firewalls and intrusion detection and prevention systems ineffective. Web application firewalls and API gateways only provide a partial solution. Bot mitigation capabilities can help by addressing the growing number of abuse scenarios.

■ Product categories, such as runtime application self-protection and application shielding, are emerging to fill gaps in application and API security. They can provide exploit mitigation, abuse mitigation and access control capabilities at different layers of an overall system implementation.

■ Modern application design and architectures affect edge and inner architecture defenses. A subset of protections and respective placement closer to workloads are beneficial, if not necessary, in protecting these modern architectures from attacks.

Recommendations Security and risk management technical professionals focusing on security of applications should:

■ Identify integrated capabilities in existing solutions, emphasizing a cloud-first approach for flexibility and favoring security as a service over virtual appliances. Use strong exploit prevention and access control capabilities — security SDKs, WAFs or RASP for exploit prevention, and API gateways — for API access control and management.

■ Deploy integrated capabilities or dedicated solutions, DDoS protection, and bot mitigation based on expected levels of application and API abuse, as well as desired level of configurability.

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Deploy protections for inner architecture to increase defense capabilities and resiliency against attacks by using API microgateways, container security and cloud workload protection platforms.

Table of Contents

Comparison...... 3 Analysis...... 9 Selecting the Appropriate Protection Levels...... 9 Selecting the Scope of Protection...... 10 Selecting Protection Against Denial of Service...... 11 Selecting Protection Against Exploits...... 12 Selecting Protection Against Abuse...... 13 Selecting Protection Against Access Violations...... 14 Selecting Protection Against Tampering and Reverse Engineering...... 15 Selecting the Right Technology Solutions...... 16 Designing for Architectural Coverage and Flexibility...... 16 Choosing On-Premises Versus Cloud-Based Solutions...... 17 Balancing Integrated Capabilities and Dedicated Solutions...... 17 Guidance...... 20 Determine the Required Levels of Protection...... 20 Prioritize the Use of Cloud-Based Security Services...... 21 Start With Integrated Platform Capabilities for Broad Coverage...... 21 Add Dedicated Solutions for Specific or Additional Protection...... 22 Edge and Inner Architecture Protection Considerations...... 22 Details...... 23 Categorizing Attacks Against Web Applications and Web APIs...... 23 Denial of Service...... 23 Exploits...... 24 Abuse...... 24 Access Violations...... 25 Tampering and Reverse Engineering...... 26 Defining Automated Threats...... 26 Multifactor and Out-of-Band Authentication...... 29 Application Security Capabilities to Address the Attack Categories...... 29 API Gateways...... 29

Page 2 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Application Shielding and Application Wrapping...... 30 Bot Mitigation...... 31 DDoS Protection...... 32 Runtime Application Self-Protection...... 33 Web Application Firewalls...... 35 Reusing Open Source to “Build Your Own”...... 37 Gartner Recommended Reading...... 40

List of Tables

Table 1. Effectiveness of Application Security Controls in Addressing the Five Attack Categories...... 7 Table 2. Architecture Components and Possible OSS or BYO Options...... 39

List of Figures

Figure 1. Comparison of Application Security Control Components...... 5 Figure 2. Determining the Appropriate Levels of Protection...... 10 Figure 3. Example Platform and Dedicated Solution Options...... 18

Comparison Web applications, mobile applications and web APIs are subject to increasing numbers and complexity of attacks. Organizations must consider several factors when planning and implementing protections, including:

■ Public, limited-access external and internal applications and APIs require different levels of security.

■ No one capability covers all types of attacks.

■ No two capabilities have interchangeable protection efficacy.

■ Some of the capabilities have strong overlaps in addressing specific attack subcategories.

■ Enforcement of policy may be centralized or distributed (for example, use of API microgateways).

As a result, a mix of capabilities, though not necessarily separate products, have to be put in place as a layered approach and tailored to the architecture that must be protected.

Gartner, Inc. | G00383318 Page 3 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Security teams should use the comparison to decide which solutions will provide their organizations’ applications and APIs with the right level of protection. Not all organizations or their applications are subject to the same level of threats and attacks, and application architectures will vary. To clearly understand the differences between capabilities, Gartner splits attacks on web and mobile applications and web APIs into five categories:

■ Denial of service (DoS) is a specific type of attack where the attacker’s goal is to disrupt the availability of the web application or service. In particular, this attack type covers volumetric attacks, which overwhelm network capabilities, and so-called “low and slow” attacks, which overwhelm application or service resources. DoS attacks may be distributed to increase the impact to availability and mitigation complexity.

■ Exploits take advantage of design, code or configuration weaknesses or vulnerabilities that cause unintended behavior of the application. Some common examples include SQL injection (SQLi), cross-site scripting (XSS), buffer overflows, and various Secure Sockets Layer (SSL) and Transport Layer Security (TLS) manipulation attacks.

■ Abuse covers many nonexploit types of attack that primarily take advantage of business logic. This includes scraping, aggregating, account brute forcing, scalping, spamming and other — often automated — scenarios.

■ Access violations occur when an attacker or legitimate user takes advantage of weaknesses in the authentication (AuthN) or authorization (AuthZ) mechanisms of a web application or API.

■ Tampering can occur when an attacker looks to reverse engineer how an application is built in order to take advantage of a weakness or structure within the application that can be manipulated or tampered with for malicious intent.

Of the five categories, only exploits can be potentially addressed by developers performing secure coding and configuration. The others require design-level considerations that cannot be reasonably compensated for in code by developers. For example, although it’s arguably possible to defend against account takeovers in individual application code, it is much more economical and error- proof to do so in an integrated identity and access management (IAM) system or another external capability.

Considering the range of exploits and abuse that can occur with web and mobile applications and web APIs, technical professionals must leverage a mix of externalized security controls to deliver appropriate protection and alleviate burdens to development staff.

Figure 1 shows how various capabilities address the five categories of attack. These capabilities may be delivered as dedicated solutions or as part of broader protection platforms. The figure does not define where and how the capabilities are delivered (for example, whether or not some are available as a service in the cloud, or as part of a larger solution).

Page 4 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Figure 1. Comparison of Application Security Control Components

Gartner, Inc. | G00383318 Page 5 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Although out of scope for this particular research, Gartner recommends evaluating workload-centric protections (e.g., API microgateways, container security solutions and cloud workload protection platforms [CWPPs]) for protecting the workload-centric or server-side portion of all architectures, as illustrated in Figure 1. For more in-depth information, refer to the following Gartner research:

■ “Container Security — From Image Analysis to Network Segmentation, Options Are Maturing”

■ “Comparing the Use of CASB, CSPM and CWPP Solutions to Protect Public Cloud Services”

■ “Using Native IaaS Workload Security Capabilities in Amazon Web Services, Microsoft Azure and Google Cloud Platform”

This research also covers some tangential technologies beyond what is depicted in the figure and that may provide subsets of application protection. These are detailed in Table 1 below.

Table 1 is an alternate representation of this comparison and includes effectiveness assessments by subcategory for each of the attack types. Several of these capabilities are available as integrated functionality within other pre-existing solutions or services, such as content delivery networks (CDNs), application delivery controllers (ADCs) and cloud platforms. Because many solution architecture patterns are possible, an organization must evaluate effectiveness in light of both the individual capabilities and the solutions in which they may be packaged. Additional technical details on the individual protection types and their effectiveness in addressing the five attack types can be found in the Application Security Capabilities to Address the Attack Categories section. Additional technical details on the attack categories can be found in the section Categorizing Attacks Against Web Applications and Web APIs.

Page 6 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Table 1. Effectiveness of Application Security Controls in Addressing the Five Attack Categories

Host-/Serv- Network-Based Capabilities er-Based Code-Based Capabilities Capabilities

Runtime Ap- In-App Web Ap- Applica- Frame- Compil- Bot Miti- Anti- API Gate- plication Application Mobile plication tion Wrap- works and er Pro- gation DDoS way Self-Protec- Shielding Threat Firewall ping SDKs tections tion Defense

Denial of Service

Network Layer High (Volumetric) DoS

Application Layer Medium High Medium Medium Medium (Layer 7) DoS

Exploit

Application Vul- Low/Medi- High Low High Medium Low Medium nerabilities um

Abuse

Brute Forcing and Low/Medi- Low/Medi- Low/Medi- High Medium Low/Medium Account Takeover um um um

Scraping and Ag- Low/Medi- Low/Medi- Low/Medi- Medium High gregating um um um

Scalping and Low/Medi- Low/Medi- Low/Medi- Low High Spamming um um um

Access Violations

Gartner, Inc. | G00383318 Page 7 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Host-/Serv- Network-Based Capabilities er-Based Code-Based Capabilities Capabilities

Runtime Ap- In-App Web Ap- Applica- Frame- Compil- Bot Miti- Anti- API Gate- plication Application Mobile plication tion Wrap- works and er Pro- gation DDoS way Self-Protec- Shielding Threat Firewall ping SDKs tections tion Defense

Low/Medi- Low/Medi- Low/ Authentication High High Medium High um um Medium

Low/Medi- Low/Medi- Low/Medi- Low/ Authorization Medium High Medium um um um Medium

Low/Medi- Low/Medi- Low/ Auditing Medium High Medium High um um Medium

Tampering and Reverse Engineering

Debugging Low High High Medium Low High

Low/Medi- Modification High High um

Code or Secret Low High High Medium Theft

SDK = software development kit

Source: Gartner (April 2019)

Page 8 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Analysis Protecting web applications and web APIs from attacks requires security teams to assess what level of security protection is necessary. In an ideal world, the highest level of protection would be available at all times or as needed, but this isn’t feasible due to complexity and cost factors. And continuously protecting all web assets with equal levels of protection can be an expensive proposition, both from economic and operational perspectives. Security teams must first pick a protection baseline. Then they must decide what extra protections are necessary to apply to specific assets.

No single security platform or solution implements the highest level of protection for all of the attack categories. Some organizations will be able to start with a single solution, but will find themselves needing greater security capabilities over time due to changes in threats and the application landscape. This leads to the question of how to implement those protections. Four intertwined factors come into play:

■ Existing solutions or platforms that can be extended to provide part or all of a capability

■ Dedicated solutions that are necessary for advanced capability in a given attack category

■ The mix of platforms with integrated capabilities and dedicated solutions to provide the appropriate levels of protection

■ The architectural and topological location of these platforms and dedicated solutions

Security teams must work with architects, developers and business owners to determine which security architecture components make the most sense. A clear understanding, among all parties, of protection levels and solution options is key.

Selecting the Appropriate Protection Levels

Selecting the appropriate protection levels against attack does not have a one-size-fits-all approach. Every organization may have varying web assets, technologies and exposed services that will dictate potential levels of risk, threat and attacks. Figure 2 represents a combined view of protection capabilities and the attacks they help mitigate.

Gartner, Inc. | G00383318 Page 9 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Figure 2. Determining the Appropriate Levels of Protection

Most organizations have a large mix of asset exposure, risk and business value. They can scope protection to best provide a baseline protection for all assets, and then determine which additional protection is warranted for some higher-risk assets.

Selecting the Scope of Protection Because of the cost and complexity involved in protection of web assets, organizations must tailor security architecture and controls to exposure, value and criticality of the target asset. Security teams should split assets into five categories to help guide their decisions:

■ External high-value or high-risk assets requiring additional protection: For these assets, you should enhance exploit protection through more advanced or redundant protection. Access control generally needs to be more capable, particularly in the authorization area. Abuse protection is essentially a necessity, at least for critical functions. And denial-of-service protection should at least be available as an on-demand option.

■ Externally exposed assets that require baseline protection: This decision is driven by compliance requirements and general web asset risk, which for many organizations means focusing first on exploit prevention and access control. Denial of service and abuse protection are a lower priority, and many organizations can generally get away with implementing only basic countermeasures in these areas by virtue of their being less of a target for attackers. But Gartner recommends planning for and being able to rapidly shift assets into the “additional protection” category if and when attacks and attackers evolve.

Page 10 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Limited externally accessible assets that require a subset of specific protection: Assets that are typically exposed for external business partner or B2B use cases should be treated like other externally exposed assets, as described in the next two categories. That is, use the baseline protections for most cases, and for high-value or high-risk assets, use additional protection.

■ Internal-only assets that require a subset of specific protection: Although the guidance in this document mainly covers the needs of externally accessible assets, internal assets, particularly high-value ones, still benefit from a subset of these protections. DoS and abuse mitigation are generally not necessary here, but Gartner recommends some exploit protection and strong access security.

Some organizations will find themselves with a need to implement high protection levels for a majority of their assets. Some may even find that they need to do so for internal high-value assets. But many can take a tiered approach, as long as they plan ahead and understand how to move to a higher level or additional mechanism in each of the categories. Once you’ve determined scope of protection for your assets, you can then move on to selecting appropriate protections against the five categories of attacks.

Selecting Protection Against Denial of Service Mitigating denial-of-service attacks is a critical availability control for some web assets. As discussed in “DDoS: A Comparison of Defense Approaches,” an important aspect of DDoS protection solutions is their capacity to handle volumetric attacks. DDoS protection is available as part of many solutions, including CDNs, cloud-based and appliance WAFs, and cloud scrubbing center (CSC) platforms. For application layer DoS attacks, hardware or cloud-based WAFs/ADCs with DDoS capabilities can be used for protection. Once the attack ramps up to become volumetric and overwhelm the network links, a CDN or external CSC is required. When it comes to volumetric DDoS protection, CSCs have distinctly different operating modes. It is important to understand how the service is applied as you select the right option for your organization, because there are financial impacts to consider. The two main CSC operating mode options are:

■ Always-on protection: Continuously protects the web application or web API and is able to mitigate attacks shortly after they commence. This is the more expensive option, and organizations may find it cost-prohibitive to do this for all but their most availability-critical assets.

■ On-demand protection: Manually activated when an attack is detected. This is a less costly option, but does require the organization to monitor web assets and have an activation plan in place.

With CDNs, each point of presence (PoP) or edge node can scrub traffic as needed, protection is always on, and vendors don’t typically redirect traffic to a scrubbing center for cleansing. In addition, organizations should look at these solutions’ capabilities — as well as the capabilities of other web security components — for nonvolumetric attacks that attempt to overwhelm web application resources. Mitigating these nonvolumetric attacks overlaps with abuse mitigation. For

Gartner, Inc. | G00383318 Page 11 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

specific, known resource denial attacks, it overlaps with exploit prevention capabilities as well (for example, high-volume-form spam and so-called algorithmic DoS attacks).

Selecting Protection Against Exploits For exploits, security teams need to work with application teams to determine which combination of capabilities provides most effective and efficient mitigation approach. The choices are not mutually exclusive. They depend on the main drivers of compliance and/or risk, as well as the organization’s capacity to perform ongoing management of the exploit protection mechanisms. Capabilities within exploit prevention controls typically include:

■ Predefined rules and signatures, which provide protection by detecting known attack patterns in the request/response patterns or the execution and/or data flow within the running code. Basic rules and signatures have somewhat limited protection capability, but also have a lower false-positive rate and are resilient to application change. When exploit prevention is required as a compliance measure (for example, when use of a WAF is mandated), this is often a default choice.

■ Custom rules and virtual patching, which allow an organization to put in place mitigations for specific vulnerabilities or attack patterns detected in regular security testing but not covered by the predefined rules and signatures. Virtual patching is an important capability for organizations that want to mitigate attacks on custom code while providing sufficient time for the application itself to be fixed. Whitelist rules provide greater protection capability, but they also require ongoing management as an organization updates its applications.

■ Behavior-based protection, which detects exploits by looking for anomalies in the request/ response patterns or the execution and/or data flow within the running code. In contrast to signatures, this method uses analytical approaches to automatically establish baselines and detect deviations. The detection efficacy and ability to deal with changes in the protected application vary by product.

These exploit mitigation capabilities are generally offered by:

■ Dedicated WAF offerings in the form of physical or virtual appliances

■ WAF offered as part of some ADCs

■ WAF offered as part of a CDN or cloud service

■ RASP solutions differing from WAF by nature of being host-based and instrumenting the application runtime, as opposed to network-based proxies

■ Limited WAF or WAF-like capabilities found in some API gateway solutions

When you aim to secure web APIs against exploits as well as abuse, ensure that the solution offers a way of training the control to “understand” how the web API is used in normal practice. This may come in the form of custom rule generation, the ability to import the web API schema definition, or automated profiling and anomaly detection.

Page 12 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Selecting Protection Against Abuse Security teams must determine how high the bar needs to be set when dealing with abuse of functionality. Abuse can manifest itself in authenticated or unauthenticated parts of a web or mobile application or web API. Attackers may be able to abuse access control mechanisms through brute forcing, credential stuffing and account takeover. These abuse cases are distinctly different from privilege escalation attacks resulting from exploitable vulnerabilities or access control misconfigurations. The level of sophistication and persistence of the abuser will be the largest factors in selecting which of the following levels of detection and deterrence is needed:

■ Detecting based on Internet Protocol (IP) reputation, which uses datasets of known malicious IP addresses or ranges of addresses to identify. These can be static or dynamic, provided and maintained by the vendor (often with ties to threat intelligence), or generated by the organization specific to its environment.

■ Caller profiling and behavioral analytics, which seek to identify the type of user agent in use or how the user is interacting with the target application. You can find these controls in dedicated bot mitigation solutions or advanced, integrated bot mitigation capabilities found in some web application security and CDN platforms. Depending on the vendor offering, these provide varying but higher levels of protection against advanced automated attacks.

■ Caller attestation, which adds a client-side SDK (usually for mobile apps) to authenticate and/or harden the client code. You can find this capability in some bot mitigation solutions, but also as a client-side add-on with mobile application shielding or mobile application wrapping solutions. It can provide an additional hurdle against API abuse, as well as help mitigate abuse of the client code itself in the case of application shielding or wrapping. Some solutions do this through device binding also.

The second part of mitigating abuse is deciding how to respond to abusive requests, because this will impact attackers’ ability to adapt their abuse tools and patterns. In addition, it impacts how much work the security and application teams have to do to configure the mitigation. Solutions usually implement one or more of the following:

■ Terminate and block the requester. This is the most straightforward method of stopping the abuse. However, it will signal to persistent abusers that they have been caught and must change their approach (and the success of stopping the attack may be temporary).

■ Rate limiting and IP blocking, which are part of most WAF and API gateway technologies. Limiting may be basic in the form of data rate thresholds, or it may be more advanced, such as permitted use of a given page or function in a set period of time. This provides only basic protection that is easily circumvented by persistent attackers, since they too can throttle requests they send. However, rate limiting and IP blocking can catch simple, opportunistic attacks. You can generally manage “nonmalicious” abusers in this way, such as aggressive search engine bots or aggregators. It can also deter some forms of brute forcing by essentially adding latency.

■ Deceive by serving a fake response or alternate content, which helps decrease the load on the back-end application, but more importantly, also does not let abusers know that they have

Gartner, Inc. | G00383318 Page 13 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

been detected. It can also throw off the usefulness of the abuse by feeding incorrect information (for example, pricing).

Organizations should start by evaluating basic capabilities as part of their existing WAF, API gateway, CDN and ADC solutions. If these do not suffice, they should look at integrated advanced capabilities. Organizations should consider dedicated bot mitigation solutions when the integrated capabilities are no match for advanced or persistent abusers. Use a real-world proof of concept or evaluation to demonstrate whether a specific solution meets your requirements of not just efficacy, but also configurability. Whether or not to add additional client-side solutions like application shielding will depend specifically on factors such as mobile API abuse patterns and the need to protect the client-side code itself.

Selecting Protection Against Access Violations Access control is principally a function of IAM systems, but security technologies can also act as policy enforcement points or policy decision points. Security and IAM professionals must work together to determine the kind of access control they want to implement and which role the security technologies will play. Assuming the IAM system provides the initial authentication and token provisioning, the subsequent access decision levels are:

■ Authentication or verification of authentication tokens, in which the security component (such as a WAF or API gateway) does not perform authentication or authorization. Its only role is to act as a policy enforcement point that allows or blocks access to the resources at a coarse- grained level. Most in-line web application security solutions implement token validation, and API gateways add other mechanisms, such as session token generation. API keys are also common identification mechanisms for calling applications but should not be used as authentication secrets.

■ Authorization controls in a centralized enforcement point, where the security component enforces access policies on behalf of the resources it protects. Its role is to act as an externalized authorization provider (EAP) that complements the IAM components. API gateways often implement this via access policy definitions or integration with federation and externalized authorization management (EAM) engines. Some WAFs are also able to do so by custom rules.

■ Dynamic access control driven by data and behavior, which means the security component not only externalizes authorization policies, but also has built-in security analytics that drive these policies dynamically. Because this mostly concerns authorization of user activity, few web security technologies implement this.

In addition to the methods by which the access policies are created and managed — by hand or automatically — organizations will need to choose how they will respond to potential policy violations. Depending on general and application-specific requirements, access control capabilities will do one or both of the following:

■ Monitor access violations during request and/or response time

■ Enforce access policy when the request is made and/or the response is served

Page 14 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

This need will also drive technology choices, because enforcement requires a different architectural setup than just monitoring: Something must act as the policy enforcement point. But technology applicability may also limit the choice, because more advanced capabilities are not available for all cases.

Selecting Protection Against Tampering and Reverse Engineering Protections against tampering and reverse engineering should address and reduce the likelihood of client-side reverse engineering, debugging, and code or functionality manipulation. These client- side attacks can potentially compromise an application or lead to obtaining sensitive data from the associated resources of the application. These protections are typically split into two categories: application shielding and application wrapping.

Application shielding criteria mainly consist of:

■ Prevention (or increased complexity) of reverse engineering, tampering or debugging on client-side code installed on mobile devices. This can be common with Google’s Android and Apple’s iOS, though some vendors also cover other binaries, JavaScript and so on.

■ Code-level obfuscation and integrity checking.

■ Rooted OS, compromised device and emulator detection capabilities.

■ White-box cryptography capabilities that hide keys in an “untrusted” application, protecting any keys in memory. Vendors may also inherently provide a level of anti-automation by nature of the implementation (e.g., SDK to enforce authentication).

■ Postcoding controls.

Application wrapping can achieve similar results as application shielding, but the protections are applied postcompilation, which is essentially safeguarding or “wrapping” the binary. Wrapping may also extend the functionality of the original application. Common capabilities of application wrapping include:

■ Integration with unified endpoint management (UEM), enterprise mobility management (EMM), mobile device management (MDM) and mobile application management (MAM) for managing mobile devices within an organization and the applications installed on them

■ Extended application functionality, such as adding SSO/IAM integrations or certificate pinning to prevent man in the middle (MITM) attacks on encrypted transit

■ Binary obfuscation

A third variation is the case of in-app mobile threat defense (MTD), or MTD delivered as an SDK. Functionality may be similar to that of stand-alone agent-based MTD solutions or MTD deployed in tandem with UEM/EMM. Capabilities help identify and block risky application behaviors, unpatched devices and mobile OSs, connections to unsecure networks, and other mobile security risks. These can also be useful in detecting forms of precursors to client-side tampering, such as enabling of development modes and/or detecting rooted and jailbroken devices. Distribution of in-app MTD is

Gartner, Inc. | G00383318 Page 15 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

within a mobile application binary as opposed to a control agent installation. Further information on MTD capabilities and distribution types can be found in the research “Comparison of Mobile Threat Defense Solutions.”

Selecting the Right Technology Solutions Security teams often first look to existing network technologies, such as next-generation firewall (NGFW) platforms and intrusion detection and prevention systems (IDPS). But these do not provide strong-enough capabilities in any of the protection areas. They are not easily integrated to intercept TLS, and do not have the same signatures, rules, behavioral analysis and business logic insight as security solutions that focus on web applications and APIs.

Organizations often first look at a “completely automated public Turing test to tell computers and humans apart” (CAPTCHA) when they suffer from abuse of functionality. But an always-on CAPTCHA creates user experience hurdles for legitimate users, and it is also no guarantee of keeping the abuser out (attackers keep finding ways to circumvent or solve many CAPTCHAs). Multifactor authentication (MFA) and out of band (OOB) challenges are often used to enable strong access control, as well as to try to thwart abuse. Unfortunately, they suffer from similar issues as CAPTCHA, and are often complex and expensive to implement.

Currently, no single security platform or solution implements the highest possible level of protection in each of the exploit, abuse of functionality, access violation and DoS mitigation categories. Some organizations will still be able to start with a single solution to address the biggest potential risks. But they often find themselves needing greater security capabilities over time due to changes in threats and the application landscape.

Designing for Architectural Coverage and Flexibility Some organizations find themselves in a situation where they have to enable protection for a specific web asset that is under attack, and then scramble to implement a point solution. Such surprises aren’t entirely preventable for all possible web attacks. This may be especially true for organizations that are not exposed to high levels of abuse of functionality and denial of service. However, planning ahead means being able to design a more comprehensive and flexible architecture that fits many application and API deployments. In addition to being more easily integrated and managed, this will also be more cost-effective.

To achieve the highest levels of protection, security decisions must be enforceable in real time (that is, at the moment the request is made, or the response is delivered). Having security capabilities integrated in-line between the client and the application or service is the easiest way of achieving this. But not all architecture and application teams are comfortable with in-line security, generally due to availability and performance concerns. Leading in-line solutions take measures to avoid such impacts, but some are also (or instead) delivered for OOB integration where an existing component calls them via an API.

Ultimately, various teams will need to perform a strong proof of concept to evaluate the solution’s efficacy and performance, regardless of its integration method. But when possible, the security capabilities should always be topologically positioned so they can be applied to any of the

Page 16 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

organization’s exposed web applications or APIs. That way, security can be adjusted if requirements change after the initial protection decision is made. For example, even though not all assets may need strong abuse protection right from the start, a targeted attack campaign may require prompt action without having to perform a complete architectural reconfiguration.

Choosing On-Premises Versus Cloud-Based Solutions Most organizations should look to use cloud-based services first for public-facing applications, because those not only have the largest potential application and API coverage, but also scale more easily than (virtual) appliances. This holds true for third-party as well as cloud-based assets. Especially when protecting cloud-based assets, it makes the most sense to use cloud services rather than limiting choice with cloud-hostable virtual appliances, which can lead to having to use multiple products to cover different cloud providers. Some organizations will still want to host certain capabilities on-premises for performance and availability reasons, because a specialized solution is not available as a cloud service, or to avoid having the cloud-hosted solution as a middleman in encrypted communications.

Although on-premises solutions — particularly in the WAF space — were traditionally more capable than cloud-based WAF services, leading vendors are working toward feature parity across hosting models in all categories. Some of the cloud-based platforms are able to bring a larger integrated set of capabilities than on-premises solutions, especially in the area of advanced protection using advanced analytics generated from monitored customer traffic. Nonetheless, security teams may need to account for constraints — such as from security capability, general architectural or compliance perspectives — and consider a hybrid or full on-premises set of solutions.

An exception to the cloud-first approach, of course, is protection of internal applications and services. In this case, the deployment topology choice is a somewhat similar one, which revolves around whether to host security capabilities as a perimeter or (also) within the application and services infrastructure. Few best practices exist for this at the moment. Most organizations will likely need to take a perimeter-style approach for security solution deployment, and augment with built-in capabilities of the application and services infrastructure to perform only a minimal amount of access-control-type security.

In the case of RASP or application shielding and wrapping, the detection or protection enforcement point will by definition be on a workload or client endpoint. But even in such a case, the analytics capabilities that accompany it could be a cloud service, and this provides a strong architectural option for mobile clients and cloud-hosted workloads. For internal applications and services, RASP and application shielding provide an add-on to the application or its runtime environment (for example, containers or managed runtimes).

Balancing Integrated Capabilities and Dedicated Solutions Many security teams feel like they’re drowning in security solutions and are wary of adding yet more technology to an already complicated stack. Additional protections may be less effective, redundant or difficult to manage. For application security solutions in particular, an additional challenge is that they are very visible to the architecture, development and business teams that create and run the

Gartner, Inc. | G00383318 Page 17 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

various applications and services. Security architecture must not create unnecessary risks to performance and availability, which can negatively impact customer experience. Security architecture must also provide the ability to troubleshoot problems when application and services request it and responses traverse multiple intermediaries.

Do not underestimate the risk of proxy overload when chaining together multiple application security architecture components.

For many clients, consolidation into the fewest number of platforms should be a guiding principle. This does not mean that capabilities are always integrated and included by default as part of a purchased license if the option exists. Rather, the starting point is to evaluate multicapability platforms first, especially those that may be in use in the organization already, or new ones that have additional benefit from a nonsecurity perspective. If none of the platforms provides the right level of capability, consider a dedicated solution and decide whether and how to integrate it in-line or out of band. This results in the least number of vendors and moving parts needed to do the job.

Shown in Figure 3 are several options for deploying protection in the five categories. The dark blue indicates network layer elements that are not solely security-focused. The lighter blue represents application layer security-focused elements. Going from top to bottom, capabilities are increasingly integrated into network-based platforms; for simplicity, host-based and OOB solutions are not shown.

Figure 3. Example Platform and Dedicated Solution Options

The most common platform options provide exploit mitigation and basic access control, and potentially abuse and denial-of-service protection. The platform categories include:

Page 18 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Cloud-based web application and API protection platforms, which combine WAF, DDoS protection and bot mitigation capabilities as the core offering, and may also provide some CDN functionality. These platforms are currently the leading option where CDN isn’t a critical requirement. Examples include F5’s Silverline, Imperva Incapsula, Oracle Cloud Infrastructure Web Application Firewall and Reblaze.

■ CDNs, which are primarily used for content caching, acceleration and routing, but now also for providing varying levels of DDoS protection, bot mitigation and WAF. These platforms currently are a prominent option where CDN is a critical requirement. Examples include Akamai Kona Site Defender, Cloudflare and Fastly.

■ ADCs, which are primarily used for load balancing, but often have add-on modules that provide WAF capabilities. ADCs are currently the starting point for teams that want to deploy exploit mitigation and basic access control on-premises. F5’s Big-IP Platform and Citrix ADC are common examples.

■ API gateways, whose primary task is to provide some combination of mediation and management for APIs, but which often have varying levels of security capabilities. These platforms should be used to complement the previous three platforms, specifically for access control of public APIs. Examples include Broadcom-CA Technologies, IBM DataPower Gateway, MuleSoft Anypoint Platform, Google Cloud Apigee and TIBCO Mashery API Exchange Gateway.

A significant challenge with these network-based platforms is that the web application security capabilities often vary greatly from vendor to vendor — even more so than for dedicated solutions. While some organizations are able to implement just an API gateway and a security platform, many will find themselves looking to fill basic capability gaps or go above and beyond what the platforms are able to offer. These technologies include:

■ Bot mitigation solutions, which provide advanced capabilities across many types of functionality abuse. They are more capable in this area than the average platform or WAF, which makes them a possible first choice or complement in abuse prevention. Example vendors include Distil Networks, PerimeterX, Shape Security and ShieldSquare.

■ WAF solutions, which provide mostly exploit protection and are available in several form factors and at several price points. They should be considered when platform-based WAF is not an option due to cost or capability. Example vendors include Barracuda, Imperva, F5, Fortinet and Signal Sciences.

■ RASP, which provides protection close to the workload and overlaps heavily with WAFs for exploit protection. This makes RASP a possible candidate for replacement of WAFs or an additional layer of security (wholesale or for specific workloads). Examples include Contrast Security, Imperva-Prevoty, Rapid7-tCell, Virsec and Waratek.

■ Application shielding and application wrapping, which are always complements to the previous solutions. They are a necessity when client-side application code tampering would present a risk to the server-side web APIs, even though some of the other solutions already provide partial client-side protection. Example vendors include Arxan Technologies-Apperian, Appdome, GuardSquare and Intertrust’s whiteCryption.

Gartner, Inc. | G00383318 Page 19 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Gartner clients also ask about security features that are part of other solutions and platforms — specifically, for those solutions relating to application development, hosting and integration. Although it would be beneficial to have strong security capabilities as part of these solutions, current capabilities are limited, and include:

■ Cloud providers, such as Amazon, Microsoft and Google, which provide various application security features, commonly in the form of API gateways or WAF capability. However, except for DDoS protection, they tend to be less capable than external solutions, or make more sense when an organization standardizes on one cloud provider for hosting its applications and services, as opposed to hybrid or multicloud strategies.

■ iPaaS and middleware platforms, which provide some security capabilities, but generally only in the form of basic access controls, rate limiting, static IP blocking and encryption. They do not have strong-enough capabilities to replace any of the external solutions other than API gateways, which are typically deployed in tandem with API management. Examples include Dell Boomi, MuleSoft Anypoint Platform and Informatica Platform.

■ Open-source solutions, which can provide some exploit protection and access control, but often don’t meet the capability levels of commercial offerings. However, clients should still consider open-source libraries and SDKs to implement security functions in software. Examples of some reusable open-source components can be found in the Reusing Open Source to “Build Your Own” section, further in this research.

In the end, the opportunity for consolidation is one of protection balance and economics. An e- commerce platform is more likely to benefit from a leading CDN and, optionally, a dedicated bot mitigation solution due to its primary DDoS protection and anti-abuse requirements. However, this type of deployment is likely too costly an option for a government organization trying to protect many different web assets, where the primary concern would generally be exploitation.

Guidance

Determine the Required Levels of Protection

Security teams will need to establish all three of the following:

■ Rudimentary hardening protections that are applied to all externally exposed resources

■ Additional protection needed for high-risk or high-value exposed resources

■ The subset of protection for internal-only resources

For each of these, they should then select from the following:

■ Options to mitigate exploits: Signatures and predefined rules, virtual patching and custom rules, and/or behavioral analytics

■ Level of defense against abuse of functionality: Basic rate limiting and blocking, advanced mitigation using behavioral analytics, or attestation of client integrity

Page 20 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Level of defense against access violations: Coarse-grained access control by token validation, fine-grained externalized authorization policies or behaviorally driven dynamic authorization

■ Methods of denial-of-service mitigation: Always-on or on-demand for volumetric network protection, and where to use exploit and abuse capabilities for application layer protection

The required protection levels drive solution selection and help ensure that the choices are effective and economical. With the high number of solution choices and combinations, it’s all the more important to avoid situations where a new application or attack requires massive changes in protection architecture. However, not all organizations can start from a clean slate, and their existing solutions and vendor preferences may negatively affect the achievable protection levels.

Prioritize the Use of Cloud-Based Security Services When given the choice between on-premises or cloud-based security solutions, security teams should advocate a cloud-service-first approach for externally hosted, public-facing applications and services. In contrast with (virtual) appliances on-premises or in infrastructure as a service (IaaS), this provides the greatest amount of architectural coverage and flexibility, as well as fully autoscaling protection to support the inherent elasticity of most cloud-native applications and APIs. Cloud- based services can offer sufficient levels of protection or similar efficacy compared to on-premises options, and several vendors offer such services in their CDN, web application and API protection (WAAP) platforms, cloud WAF, and API gateway products.

Exceptions to this approach include:

■ Internally hosted, nonexposed applications and services, where best practices often do not dictate a specific level of protection. In that case, security teams should generally opt for built-in capabilities in application and services infrastructure, possibly with an internal WAF-like or API gateway “perimeter.”

■ Cases where the organization is simply not comfortable with cloud-based security solutions, or where compliance and regulatory restrictions limit its use.

Start With Integrated Platform Capabilities for Broad Coverage

Firewall platforms and IDPS solutions are not sufficient for protecting web applications and services. But several platforms — some of which may already be in use by an organization — can provide strong protection in several categories. The most common examples include:

■ CDN and ADC platforms that offer security add-ons

■ WAF solutions that have grown into larger web application security platforms

■ API gateways that have grown to offer various security capabilities

Organizations should start by evaluating platform solutions first, and many will find they need to combine a CDN, ADC or WAF-type solution with an API gateway. Again, the key is to look for

Gartner, Inc. | G00383318 Page 21 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

existing platforms that can be extended, or new platforms that offer significant combined capabilities across protection categories. This minimizes the number of moving parts, and prevents “proxy overload,” which can lead to excessive performance and availability risk.

Add Dedicated Solutions for Specific or Additional Protection Ideally, a single platform would integrate all required protection, but two obstacles may appear: the required level of protection exceeds platform capabilities, and/or existing platforms cannot be changed out for one with strong security protection. As a result, security teams will likely need to evaluate one or more dedicated solutions to fill protection gaps.

Particular requirements should drive product selection:

■ Bot mitigation solutions for particularly challenging abuse cases

■ Stand-alone WAF when a cloud WAF or WAAP is not an option or lacks capabilities

■ RASP to augment or eventually replace a WAF for exploit protection in particular

■ Application shielding or wrapping for extra assurance that client code cannot be tampered with

Edge and Inner Architecture Protection Considerations

Traditional monolithic architecture is being replaced by microservices architecture (MSA). Therefore, security considerations should be weighed not solely on the edge, but also in the inner architecture including the containers that power microservices, the service meshes that orchestrate them and/or the APIs that get exposed.

North/south (i.e., traffic inbound to MSA) and east/west (i.e., traffic between workloads within an MSA) communications and interactions differ in security threats, access controls and trusted links between workloads or services. Therefore, the protections implemented should be tailored to the specific threats and attacks at the edge and within the inner architecture. In most cases, it makes more sense to deploy exploit and abuse protections at the edge, while inner architecture protections are access-control-focused, such as enforcing mutual TLS authentication of workloads. Workload protection and container security tools often include IDPS-like capabilities to detect and block potential workload compromises. Like traditional IDPS, though, these are also less focused on web application or API attacks. They may be helpful in identifying issues such as command injection or shell misuse in containers, but they are less likely to detect or block an attack like XSS.

Relevant inner architecture protections include API gateways, API microgateways, container security, CWPPs to protect the workloads, or APIs that power modern web and mobile applications. These elements must be accounted for when evaluating your complete set of application protections.

For additional reading and more in-depth detail on CWPP and container protections, refer to the following Gartner research:

■ “Comparing the Use of CASB, CSPM and CWPP Solutions to Protect Public Cloud Services”

Page 22 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ “Market Guide for Cloud Workload Protection Platforms”

■ “Container Security — From Image Analysis to Network Segmentation, Options Are Maturing”

Details

Categorizing Attacks Against Web Applications and Web APIs Application protection is not just about detection and prevention of traditional vulnerabilities like injection flaws. It also includes protection against general abuse from automated attacks, as well as business logic abuse. If the application contains client-side elements, then tampering and reverse engineering are also in scope for protection. Rounding out the areas of concern are denial of service and access violations, which can negatively impact availability and access control, respectively.

Denial of Service DoS attacks are aimed at consuming resources within networks, systems and applications to make the services unavailable to legitimate users. At a high level, attacks fall into two categories:

■ Volumetric network layer: Also referred to as “flood,” designed to overwhelm delivery systems or networks or the network “pipe.” User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP) and SYN are some common specific flood types. Generally measured in a data rate per second, such as Tbps or Gbps, this attack consists of high volumes of smaller packets, often requiring the use of a botnet to achieve the high data rates.

■ Nonvolumetric application layer: Also referred to as “Layer 7 DoS,” designed to overwhelm the running application and application server. Commonly, these are over HTTP and include HTTP GET floods, specifically crafted high-impact HTTP requests, resource-intensive database queries and triggering complex algorithm computations. It can also include business logic abuses, such as abusing file or messaging functionality to spam other users and cause performance degradation on the running application or other applications and systems. Generally, these types of DoS attacks are measured in requests per second, since they don’t require the same high volume of requests to create the DoS condition within the targeted application.

It is important to clearly define “bots” and “botnets” as used in attacks:

■ Bot: An attacker can create a bot for malicious purposes to generate a DoS (or DDoS) condition at the network or application layer. An attacker can also create a bot designed to exploit or abuse a target application.

■ Botnet: A network layer DoS or DDoS typically requires the use of a botnet to generate the necessary high volumes of traffic to overwhelm network pipes. A botnet is a larger collection of bots or systems, often in the form of compromised hosts, including desktops, mobile devices or things (as in IoT). Some recent common examples of botnets include Cyclone, Mirai, Nitol and Sentry MBA.

Gartner, Inc. | G00383318 Page 23 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

DoS conditions are typically readily identifiable through traffic analysis and examination of how the attacker impersonates legitimate users (or machines) by manipulating HTTP headers, specifically the user-agent string. These fingerprints or signatures aren’t necessarily static, either. A bot or botnet used for DoS purposes may run through thousands of permutations of these impersonations, such as in the case of Nitol.

For more details on the topic of DDoS, see “DDoS: A Comparison of Defense Approaches.”

Exploits Web application exploits make use of vulnerabilities like injection flaws, commonly SQLi, but also issues like XML and Lightweight Directory Access Protocol (LDAP) injection. Cross-site scripting, or XSS, is also a well-documented, yet still prominent, vulnerability in web applications.

Other common issues include cross-site request forgery (CSRF), weak or broken session management, unsecure direct object reference, and open redirects. These application vulnerabilities are covered extensively in vulnerability lists like the “OWASP Top 10 Project.” They are also generally domain-agnostic, occurring regardless of the underlying business logic.

This type of vulnerability detection is an area in which security tools (such as AST) and security architecture (such as WAFs) generally excel, because it is simpler to detect these issues programmatically and automatically through traffic analysis. The security software does not need to fully “understand” what the underlying application is doing or how the user interacts with it to detect these types of vulnerabilities. It can observe requests and responses, most commonly HTTP, to uncover exploit patterns. However, as you move into attacks against business logic, it becomes a more complex problem. It requires that the security software have a deeper understanding of what the application is designed for and how users interact with it, necessitating more advanced techniques like guided scanning and behavioral analysis.

Abuse Beyond exploits, abuse is the category of attacks more specific to business logic. In most cases, these types of attacks aren’t taking advantage of specific weaknesses in the underlying code. Rather, the attacks are using the application and services they were designed for, but in some abusive or unexpected way. Mapping this to API abuse, the closest official definition we have is Common Weakness Enumeration (CWE) 227, which generalizes abuse as a violation of the “contract” between client and server (or caller and callee). The contract includes all the explicit and implicit expectations in API consumption between both parties, including:

■ Methods of communication (such as HTTP/HTTPS protocols)

■ Permitted frequency of use or communication

■ AuthN and AuthZ

■ Data formats

Business logic abuse is specific to your environment and application design, as well as your industrial and economic sectors. Attackers can and often do automate these abusive behaviors,

Page 24 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

initiating the discussion of bots and bot mitigation, which we cover in the Defining Automated Threats section. For simplification purposes, we’ve categorized abuse into three subcategories. This is so that we can account for the largest percentage of issues that organizations are facing and map those to application protection capabilities. The subcategories are:

■ Brute forcing and account takeover

■ Scraping and aggregating

■ Scalping and spamming

Access Violations Access control for web applications and web APIs, including integration with other IAM systems, should be considered a baseline security control. There are cases where AuthN and AuthZ may be defeated, but barring an exploit such as SQLi, this typically results from issues such as:

■ Security misconfiguration

■ Unprotected URLs

■ Improper assignment of roles or permissions, or not using principle of least privilege

■ Lax identity, password and account lockout policies

■ Overly simplified flows for forgotten usernames and passwords, as well as password update mechanisms

■ Insufficient session entropy

■ Extended session timeouts

■ Compromised credentials from other incidents or breaches, possibly external to the organization (i.e., phishing/credential phishing)

When employed properly, access control can buy a minimum level of security that may in some use cases be sufficient to address the majority of threats you are concerned with. Still, for any exposed endpoint, you need to consider the likelihood of abuse in the form of brute forcing. IAM, transport encryption and API keys raise the bar for security and access control, but they are not advanced enough for abuse scenarios. Each of these controls has benefits and limitations:

■ IAM will help mitigate some attack traffic by necessitating registration and login. However, attackers may be able to automate and circumvent simpler enrollment and provisioning processes. Stronger authentication may be required. Authentication needs to be strengthened beyond, yet is often combined with, IAM.

■ Transport encryption, where you should use TLS 1.2 or newer, guarantees that under normal circumstances, data gets encrypted in transit to prevent snooping or MITM attacks. However, an attacker can observe client behavior and craft encrypted requests to URL endpoints, just as a standard user would.

Gartner, Inc. | G00383318 Page 25 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ API keys provide a method for identifying and controlling versions of APIs and services or users that connect to you. You can revoke these as a form of basic blocking ability in cases where partners or users are consuming services in ways you don’t intend. Many implementations of API key mechanisms are basic, where keys are not secret and can be harvested from traffic or client-side applications.

Tampering and Reverse Engineering Tampering and reverse engineering primarily revolve around client-side reverse engineering, debugging, and code or functionality manipulation. These client-side attacks can compromise applications and lead to the theft of sensitive information from any associated resources of the application, or from within the application directly. Attacks may come via Android Application Package (APK) or Apple’s iPhone Application Archive (IPA) decompilation or disassembly, the use of debuggers to control application functionality or code control flow, and manipulation of client-side JavaScript, such as the method of Magecart.

Defining Automated Threats A bot, in the web context, is simply some entity that initiates sequences of HTTP requests and processes HTTP responses to exercise application or API functionality in an automated way. The terminology of bots carries some negative context, largely due to intermingling with botnets leveraged in network layer DoS and DDoS attacks, as mentioned earlier. Bots are neither good nor bad by definition. They are a necessity and catalyst for innovation in the age of modern application design, mobility and automation. Some general criteria for bots include:

■ Interact with web applications and web APIs to utilize functionality and interact with data

■ Mimic the behavior of a user in a web UI or thick/mobile client, which in turn generates HTTP traffic

■ Can be created in basic form, existing as something simple like a Python script or a set of Wget or cURL commands

■ Can exist as compiled code or headless browsers that can reproduce feature sets of traditional web browsers, including processing JavaScript

■ May exist within web browsers as legitimate plug-ins or injected code in case of infected web browsers

Attackers commonly leverage bots and botnets for DoS and DDoS attacks, as well as for spamming and fraudulent purposes. However, bots also demonstrate a wide range of application-specific behavior. Distil Networks maintains an online inventory of bots that it analyzes and/or mitigates, which it then seeks to classify as “good” or “bad.” Imperva also maintains a similar directory in the form of the BotoPedia.

The measure of good or bad is relative to your organization, the target application and business logic in question. Some common examples of good or desirable bot behavior include:

■ Search engine indexers, such as Google and Microsoft’s Bing

Page 26 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Content aggregators, such as Intuit’s Mint and Travelocity (from a customer perspective)

■ Feed fetchers, such as with RSS feeds, social media apps (Facebook, Google, Twitter) and native mobile frameworks (Android, iOS, Windows Phone)

■ Legitimate scrapers, such as Wayback Machine, which catalogs and archives internet content for historical purposes (for most geographical locations)

■ Price scrapers in e-commerce provider use cases where price matching or price competition is promoted

■ Content scrapers and aggregators in e-commerce provider use cases that leverage a trusted reseller network

■ Expected vulnerability scans as part of a regular vulnerability assessment (VA) or AST

Common examples of bad or undesirable bot behavior include:

■ Overly aggressive search engine indexers, such as Baidu

■ Content aggregators, such as Intuit’s Mint and Travelocity (from a financial institution perspective)

■ Unwanted third-party scrapers and aggregators in the travel, hospitality or real estate industries

■ Scalpers, such as in the case of presales of tickets or scarce items

■ Spammers that seek to overwhelm users with excessive content (emails, messages, etc.)

■ Bots designed to skew search engine optimization (SEO), advertising clicks and marketing analytics

■ Bots that unnecessarily consume on-premises or cloud resources, resulting in increased expense for the organization

■ Unexpected vulnerability scans, for the attack purpose of finding vulnerabilities to exploit

■ Bots used in perpetrating gift card fraud

There are certainly cases where bots are perceived as both good and bad, like in the cases of vulnerability scanners and aggregators. Security testing teams and attackers will sometimes use the same tools to test for vulnerabilities in applications and APIs. Excluding cases where legitimate HTTP scans are stamped with something like a custom cookie, you can’t always make the determination based on the type of traffic alone and need to examine the requesting party. Aggregators present a unique situation, where the intended use is desirable for customers but may be undesirable for the providers, since it can raise customer support issues. Intuit’s Mint is a good example of this as a mobile banking app that aggregates financial services. Intuit maintains the mobile app, but the financial service providers maintain and operate the linked financial accounts. Who does a customer contact for support in case of an issue: the creator of the mobile aggregator app or the provider of the service that is being aggregated?

Gartner, Inc. | G00383318 Page 27 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

You must take into consideration these gray areas of desirable and undesirable bot behavior in your mitigation strategy. It’s not a question of “good” versus “bad” bots, and blocking bots universally is not an effective strategy. You need to have greater visibility into what bots are doing so that you can take intelligent action on what to do with them. You also need granularity and selectivity on the actions you do take against certain bots, beyond basic blocking or allowing. General reaction capabilities for bot mitigation, from basic to advanced, include:

■ Block or allow the request

■ Throttle or rate-limit the requester

■ Serve alternate content to the requester

■ Serve an interactive challenge or reverse Turing test (such as Google reCAPTCHA) to the requester

■ Serve a proof of work in the form of code to be processed automatically and programmatically by the requesting user agent

Capabilities vary across vendor product types and offerings, and advanced controls are more commonplace in the dedicated solutions. For some organizations, it’s becoming increasingly important to implement sophisticated bot management capabilities to effectively manage good and bad bot behavior, rather than bot blocking and mitigation to restrict bad bot behavior.

Open Web Application Security Project (OWASP) maintains the Automated Threat Handbook, which details the various types of automated threats organizations face across industries and sectors and may be useful as a taxonomy for bots or bot behaviors.

The topic of fraud, particularly in transaction and payment processing, is a separate discipline and function from what we cover in this research. Traditionally, organizations take a more reactive approach in other back-end systems and processes. However, it is important to note that organizations may be able to leverage bot mitigation capabilities as a preventive control in certain fraud cases, including the following OWASP-defined automated threats:

■ OAT-010 Card Cracking — “Identify missing start/expiry dates and security codes for stolen payment card data by trying different values”

■ OAT-001 Carding — “Multiple payment authorization attempts used to verify the validity of bulk stolen payment card data”

■ OAT-012 Cashing Out — “Buy goods or obtain cash utilizing validated stolen payment card or other user account data”

Similarly, click or ad fraud and skewing of marketing analytics fall in the broad category of general fraudulent activity. The same bot mitigation capabilities can also be useful in combating these automated threats. OWASP defines these additional fraudulent threats as:

■ OAT-003 Ad Fraud — “False clicks and fraudulent display of web-placed advertisements”

■ OAT-016 Skewing — “Repeated link clicks, page requests or form submissions intended to alter some metric”

Page 28 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Multifactor and Out-of-Band Authentication Note that IAM offerings are outside the focus of this document. However, you can find in-depth analysis on MFA and OOB challenges, including how they fit into cloud-hosted scenarios and the overall IAM picture, in the following Gartner research:

■ “Enterprise Adaptive Access: Are We There Yet?”

■ “The Evolving Architecture of Modern Identity”

■ “Cloud-Based MFA Services Deliver Fast Time to Value for User Authentication”

■ “Guidance Framework for Managing Consumer Identities”

MFA and OOB challenges help mitigate automated attacks in some cases, but can also create some additional hurdles, depending on their implementation, namely:

■ They can break “good” automation and prevent communication from bots we want to allow. It generally won’t work for machine-to-machine communication unless a method like certificate- based authentication is used, since machines can’t process the interactive challenges.

■ Setup can be complex or require additional SDKs for integration. Increasingly, they are used in an adaptive or selective way so as not to burden the end user, which adds further complexity.

■ Vendor offerings may work for certain use cases or access methods, but not all. As an example, a solution designed only for the mobile channel, such as a one-time password (OTP) via SMS, can’t provide MFA for web-only users or APIs.

■ They can negatively impact user experience in native rich-client mobile app use cases, similar to CAPTCHA, but arguably less intrusive. Users have to take themselves out of the mobile app to retrieve the necessary information and then switch context back to the app to answer the challenge.

Application Security Capabilities to Address the Attack Categories

The sections that follow cover the most significant application security architecture capabilities in greater detail. Effectiveness in addressing the five categories of attack is defined for each protection type, as well as additional technical details on the technology and some example vendors.

API Gateways Many modern applications use APIs, and properly securing APIs requires more than secure coding and a WAF. Most development teams are familiar with basic security, such as authentication and the use of TLS, but more advanced security requirements have to be added externally. API gateways and API management solutions focus primarily on the development and management of the APIs, but they also offer varying levels of security features that mostly focus on access control and some mitigation of abuse:

Gartner, Inc. | G00383318 Page 29 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Security management, in particular the management of access control policies, encryption policies and basic threat protection policies.

■ Authentication using access tokens, basic authentication and X.509 certificates, as well as application identification via API keys. Integration with IAM systems is common and considered a best practice.

■ Authorization using policy definitions, as well as basic abuse prevention in the form of rate limiting and IP blocking.

■ Content inspection and data transformation.

The products are platforms in and of themselves, and work alongside IAM and other security solutions. Most are available as a cloud service, and some can also be deployed on-premises or in IaaS as a virtual appliance. Example vendors include Broadcom-CA Technologies, Google Cloud Apigee, IBM, MuleSoft and TIBCO Software.

Application Shielding and Application Wrapping With the rise of mobile apps and the IoT, the related APIs are an increasingly attractive target for attackers. Similar to the APIs used by JavaScript-driven web applications (and sometimes even the same API), attackers will attempt to obtain the necessary access — API keys or credentials, or both — to exploit and abuse them. Clients report that abuse attacks will often target the browser API first, but swiftly move to the mobile API once the browser API has been more heavily protected. In some cases, attackers analyze the client code or API traffic directly to find exploitable weaknesses in code or business logic.

Application shielding and application wrapping solutions attempt to raise the bar on successful attacks. The main focus of these solutions is to make the client code less easy to reverse engineer, debug or tamper with. They implement one or more of the following capabilities:

■ Obfuscation and encryption of the code or compiled binary, to frustrate attempts at reverse engineering.

■ Runtime checks for application integrity, to ensure that the code or compiled application has not been tampered with.

■ Runtime security checks to detect compromised environments or suspicious activity, such as jailbroken/rooted devices or debugging and emulation, respectively.

■ Hardened cryptographic code (“white-box cryptography”) to protect client-side secrets and sensitive data, such as static (hard-coded) or dynamic API keys, encryption keys or credentials. Often used in high-value transactions and mobile payments.

The application shielding and application wrapping solutions are generally platform-type-specific. Mobile solutions support iOS and Android native code, and possibly the JavaScript used in web hybrid apps. Other solutions exist for server and desktop languages, such as Java, .NET and C. Example vendors in these categories include Appdome, Arxan Technologies-Apperian, Blue Cedar, GuardSquare, Inside Secure, Irdeto, PreEmptive Solutions and Intertrust’s whiteCryption. Some

Page 30 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

solutions, such as those from Jscrambler, specifically target JavaScript. Bot mitigation solutions often also include some mobile and/or JavaScript protection component.

Bot Mitigation Bot mitigation, sometimes referred to by vendors as “anti-bot” or “anti-automation,” can be used to mitigate or block automated attacks. Their primary focus is in the abuse attack category, but can also include exploit attack types in some cases. The solutions accomplish this through some combination of the following:

■ Comparing traffic and header data against pre-existing, known bot signatures.

■ Analyzing HTTP header data to detect anonymities, such as manipulated user agent strings.

■ Verifying IP address and autonomous system number (ASN) origin to determine whether the HTTP header data matches where the request is originating from.

■ Evaluating IP reputation:

■ Static type, where request originates from a known bad IP address for a bot.

■ Dynamic type, where bots or botnets rotate IP addresses or use ranges to evade basic IP and rate-limiting controls.

■ Fingerprinting the user agent or device.

■ Injecting client-side JavaScript code into the traffic for web application use cases to provide:

■ Seamless client challenges in the form of proof-of-work puzzles or Turing tests.

■ Cryptographically secure client/server authentication.

■ Utilizing JavaScript polymorphism, which entails modifying field elements on the page, altering order of elements, injecting new variables, etc., to throw off preprogrammed bot behavior. A potential side effect of this technique is that it can break accessibility features.

■ Offering an SDK to provide cryptographically secure client/server authentication in use cases where mobile applications communicate with web APIs.

■ Tracking of a pre-existing session cookie or device ID in the HTTP traffic. This is useful in machine-to-machine or direct web API communication.

■ Gathering metrics and telemetry on the user for behavioral analysis, including how the user or machine is generating requests and processing responses.

Vendors make use of these techniques in varying capacities, especially across the web, mobile and web API use cases. Focusing exclusively on the use of a JavaScript wrapper will rule out the use cases for mobile native rich clients or direct web API communications. This client-side JavaScript may or may not be hardened, encrypted or obfuscated. Attackers can still analyze and reverse engineer obfuscated code; it’s just not easily readable by humans. When obfuscating source code, system functions can’t be renamed so that the code remains runnable. Attackers employing reverse

Gartner, Inc. | G00383318 Page 31 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

engineering techniques can take advantage of this by mapping system functions to obfuscated function names and analyzing data flow to make sense of the obfuscated code. For this reason, many vendors have moved away from obfuscating the client-side JavaScript and do not consider that piece to be secret.

It’s important to recognize that bot mitigation capabilities are both preventive and reactive. They are partially preventive through use of techniques like signature matching, IP reputation and user agent challenges. They also rely on behavioral analysis to detect and block more advanced threats, which is a reactive approach. There may be delays in cases of new attacks or persistent, evolving threats, since behavioral analysis is required to identify the new patterns and tune the bot mitigation policies. In some cases, particularly with the additional expense of “white glove” or managed service, vendors will assist in the attack analysis and make recommendations to mitigate the abuse.

Bot mitigation capabilities exist as dedicated offerings as well as integrated capabilities within CDN, WAF and API gateway components. The deployment model usually consists of some combination of cloud-based and on-premises components closer to the application and application servers in the form of a physical appliance, virtual machine or installed software. The dedicated offerings may also include (usually at an additional cost) some form of managed service and/or data science team interaction for monitoring and fine-tuning of the solution as automated threats adapt. Configurability can also be a differentiator, since some vendor capabilities may not offer granularity in customization to isolate different types of bot traffic and take varying action. Some dedicated bot mitigation vendors include Cequence Security, Distil Networks, PerimeterX, Shape Security and ShieldSquare. There are also offerings from CDN vendors, including Akamai, Imperva and Instart. Finally, some vendors focus on mobile application authentication, which can help mitigate bots and abuse cases, such as in the case of CriticalBlue, Entersekt and KOBIL Systems.

DDoS Protection DDoS protection, particularly for network scenarios, is largely beyond the scope of this research, since effective mitigation involves different skills and strategies across the internal, edge, external and people/process layers. For more details on the topic, see “DDoS: A Comparison of Defense Approaches.”

Generally speaking, capabilities to address application layer DoS are better employed at the internal or edge layers, such as within WAF and ADC components. This is largely because of where they sit within an internal network, which results in:

■ Visibility of decrypted traffic after SSL/TLS termination

■ Higher application “awareness” by nature of being closer to the running application

■ Not needing to be a first line of defense against volumetric attacks

However, application layer DDoS protection capabilities found in IDPS, WAFs and ADCs can be a double-edged sword as a result of providing deeper levels of packet inspection. Potential downsides include:

Page 32 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Susceptibility to volumetric DoS by going deeper in the application stack to gain more application awareness. It introduces more overhead and latency, which inadvertently makes them targets for network layer DoS attacks.

■ Increased potential for an economic DoS if the capability is cloud-based or SaaS. It can become cost-prohibitive to deal with excessive amounts of traffic.

■ Potential need to “fail open” so as not to impact users or business in the event of failure or overwhelming of the control.

■ Additional capabilities required in separate appliance(s) at the external layer to address volumetric DDoS attacks.

Some example vendors in the DDoS protection category include Akamai, F5, NETSCOUT (Arbor Networks), Neustar, Radware, RioRey and Verisign.

Runtime Application Self-Protection RASP shares similarities with interactive application security testing (IAST) tools in how it instruments code to gain visibility. However, RASP is used as a production security control and not a security testing solution like IAST, which is typically run in nonproduction environments. Some vendors offer their technology for both use cases. However, features and/or platform support may exist for a given IAST solution, but not the RASP variation. There may be delays as vendors add features to one of the two product variations. The range of supported functionality and platform compatibility vary greatly between vendors.

RASP offers high-accuracy attack mitigation, especially for injection-type attacks, by having deep visibility into the application stack. It also scales and moves with applications through its integration into the runtime environment (RTE) or instrumentation libraries, reducing some of the WAF challenges, but not replacing WAFs outright for all capabilities. RASP capabilities focus on interpreted languages (i.e., those that compile into bytecode or some variation of it) and take either an SDK or host-based agent approach. SDKs require that developers integrate the RASP function calls directly within the codebase. Host-based agent approaches require that you install and instantiate a separate agent or sensor on the application server.

The host-based agent approach is more developer- and administrator-friendly, essentially embedding the RASP functionality in real time into the running application code within the RTE. In this regard, RASP shares some similarity to application performance monitoring (APM) solutions in design philosophy, but RASP serves a security purpose, as opposed to performance monitoring and optimization in the case of APM. RASP and APM solutions should be compatible, since RASP is essentially another agent to invoke as part of the runtime. Nonetheless, it is important to verify compatibility of the two technologies if you instantiate both on a given application server (see “Hype Cycle for Application Security, 2018”). There is future potential for merging or integration of RASP and APM client-side pieces, which could minimize the number of agents necessary to instantiate on a given application server. RASP solutions commonly leverage a central console, hosted on- premises or in the cloud, which collects data from the agents, sensors and SDKs, and controls

Gartner, Inc. | G00383318 Page 33 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

security rules and protection levels. When considering requirements and vendor offerings, you must account for support of:

■ Runtime environments, such as Java, .NET, Node.js, PHP, Python and Ruby

■ Application server types and versions, such as Apache Tomcat, IBM WebSphere Application Server, Internet Information Services (IIS) and Red Hat JBoss Enterprise Application Platform

■ Application framework type and version, such as ASP.NET, Java EE, Spring and Struts

■ Middleware and database types and versions, such as Java Database Connectivity (JDBC), Microsoft SQL Server, MongoDB, MySQL and Oracle

For a load-balanced, n-tier application, RASP requires that agents be installed and maintained on all tiers and servers, which can create an operational burden on infrastructure teams. While the agents are designed to consume minimal resources in the range of low-single-digit percentages, there is still the concern that they can degrade performance of a given application and application server in production. Combining this with other non-RASP agents that may be instantiated on a given application server, there is potential for performance degradation or incompatibility. While vendors do try to test and account for these scenarios, a given application setup and environment can be incredibly complex and beyond the realm of normal test setups. Like any host-based technology, proofs of concept and evaluations are critical, especially because they can negatively impact production application usage.

Client-side exploit and abuse protection is typically out of scope for RASP capabilities and more in the realm of application shielding, sometimes branded as “mobile RASP.” RASP in general is not appropriate for most types of DoS mitigation and certain anti-automation approaches. Some vendors will mitigate against certain Layer 7 cases, such as brute forcing and account takeover. Additionally, further points of differentiation between the vendors to be aware of include:

■ Ability to create or modify rules to protect against exploitation of custom business logic.

■ Ability to inspect every request, or only specific ones, which may impact accuracy as well as performance.

■ Inherent software composition analysis (SCA) capability, identifying known vulnerable components within the application codebase that have published common vulnerabilities and exposures (CVE) identifiers. Contrast Security offers one example of this, as it provides a capability it brands as “CVE-shield” that can block the known exploits against the given vulnerable piece of code.

■ Product focus on protecting the RTE itself. These offerings tackle exploits and abuse of the application, but also address security and integrity of the RTE, somewhat akin to host-based intrusion prevention systems (HIPS). This product subtype seeks to mitigate attacks that attempt to violate the boundaries of the application sandbox with attacks such as buffer overflows/underruns, return-oriented programming (ROP), and stack or memory exploits. Coincidentally, this RASP variant is a potential fit for certain IoT use cases, where an organization needs to protect embedded code running within the RTE on some piece of hardware. Example vendors include Virsec and Waratek.

Page 34 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Product focus on data security and protection, such as with SecuPi.

■ Virtual patching, similar to WAFs or IDPS, but blocking the potential exploit at the RTE layer, as opposed to the network layer in HTTP traffic. This can ease patch management headaches and bug-fix prioritization and scheduling.

Example RASP vendors include Contrast Security, Hdiv Security, Imperva-Prevoty, Micro Focus, Rapid7-tCell, ShiftLeft and Trend Micro-IMMUNIO, as well as the vendors SecuPi, Virsec and Waratek mentioned above.

Web Application Firewalls These devices or controls are designed to protect web applications that an organization hosts, whether they be homegrown, acquired or commercial off-the-shelf (COTS). They are commonly employed to protect internet-facing, public web applications and web APIs. They can also be used to protect web applications and web APIs designed for internal employee use or shared with trusted business partners. WAFs generally accomplish their task through the use of:

■ Filters, which are essentially pattern-matching rules for HTTP traffic to mitigate risks of attacks like XSS and SQLi. The approach can be either:

■ Whitelisting, or allowing only known good patterns. This results in lower false-negative rates, but higher false positives. In other words, the WAF may catch and block more attacks, but it may also be overly aggressive in blocking legitimate users that appear suspicious. Whitelisting is generally a more complex endeavor, since you have to establish a baseline for what is acceptable traffic. It may also be challenging for applications or web APIs that change frequently or have many nested URLs, requiring regular WAF filter tuning and application profiling.

■ Blacklisting, or blocking known bad patterns. This results in lower false-positive rates, but higher false negatives. In other words, the WAF will potentially miss attacks, but it will not run the risk of blocking traffic that is suspicious yet benign. Vendors usually provide blacklists OOB and may update the patterns regularly, particularly for known exploits against COTS applications.

■ Transforms, which are essentially manipulations of the original HTTP traffic to apply added levels of protection. This includes:

■ URL encryption

■ Cookie signing

■ Injection or integrity checking, or anti-CSRF tokens to explicitly detect or block CSRF attacks

■ Enforcement of cookie protections (e.g., httponly, secure)

The Payment Card Industry Data Security Standard (PCI DSS) helped drive the adoption of WAF technology. Specifically, WAF is one of two listed controls that can satisfy Requirement 6.6, with the

Gartner, Inc. | G00383318 Page 35 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

other being that the organization performs AST. Satisfying compliance and appeasing an auditor do not equate to security, however. Standing up a WAF and performing no configuration, tuning or profiling will result in an ineffective control. It is common for these devices to be configured in monitoring-only mode, rather than active blocking. So, while they may detect a web application attack, they will take no action to prevent or block it.

WAF capability may be integrated into or offered through other components, such as API gateways, ADCs and/or CDNs. There are also variations of WAF product design, such as with Signal Sciences, which use a combination of host-based and network or cloud-based components. WAFs exist as traditional, physical appliances but also as virtual machines or cloud services. They can also be hosted on-premises or in the cloud within an IaaS provider, or some hybrid of the two. Deployment options are dependent on the vendor and product, and may also impact the available functionality. Typically, the options are one of the following:

■ Network-based in-line acting as reverse proxy, transparent proxy or network bridge. In-line is typically preferred as a “catchall” to provide higher accuracy, but this approach can create operational risk in the event of failure or latency if the appliance can’t handle the traffic load.

■ Network-based OOB deployment.

■ Host-based.

■ Cloud-hosted.

WAFs may vary in effectiveness of exploit prevention based on the type of web APIs you seek to protect. It is common to see protection of SOAP or XML-RPC-based web APIs, but support for modern, commonly used RESTful types may be limited or nonexistent. Also, similar to the challenge within the practice of AST, training a tool to understand API schemas can be particularly challenging. Some WAFs can be trained by importing API schema metadata, such as a Swagger definition file for REST APIs, or Web Services Description Language (WSDL) in the case of SOAP APIs.

Related to this challenge of APIs is the concept of application profiling and WAF tuning. In many cases and for highest effectiveness, you will need to generate filters with specific patterns for custom applications you create or host. Some maintenance tasks or operational hurdles you should be aware of when employing WAFs:

■ WAFs may fall within the realm of responsibility of network teams, as is the case with other network controls like firewalls and IDPS. However, these teams may not have enough insight into the application (as a result of separation of duties) or possess the necessary expertise to tune the WAF. Maintaining an effective WAF configuration likely requires involvement from development, infrastructure and security teams, as appropriate.

■ Regular changes in custom-developed applications will also require regular maintenance and monitoring of the corresponding WAF rules to ensure effectiveness in catching attacks, but also not blocking legitimate users. This can pose additional challenges for applications developed with agile methodologies, where code changes frequently.

Page 36 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Some vendors will offer a type of dynamic application profiling to ease the burden of manually creating and tweaking WAF rules. While these sound promising on paper, particularly complex applications may complicate the problem, and dynamic profiling may not work as advertised.

■ Most vendors will offer a form of virtual patching, which can be an effective way of blocking exploitation of vulnerabilities that an organization can’t fix immediately. This can be useful for cases where it takes time to develop a bug fix internally or coordinate distribution of patches provided by a vendor for COTS software. It may also be useful in cases where the protected application can’t be fixed at all, such as when an application vendor refuses to fix the underlying issue, or it has gone out of business. Virtual patching typically makes use of results from AST tools to generate corresponding WAF rules to block exploitation of identified vulnerabilities from security testing.

■ There may be variations of attack patterns that can enable an attacker to bypass the WAF, such as using alternate encodings or multiple rounds of encoding. WAF evasion is a regular technique employed by attackers and security analysts. In addition to ensuring WAF rules and software versions are kept up to date from the vendor, OWASP maintains a list of common WAF evasion techniques, which you should review:

■ SQLi

■ XSS

Example WAF vendors include Barracuda, F5, Fortinet, Imperva and Signal Sciences.

Reusing Open Source to “Build Your Own”

As with many IT initiatives, there is the potential desire to make use of open-source software (OSS) options to avoid costs. Taking this “build your own” (BYO) approach may be a way to reduce expense in software investment. However, you still must account for time needed to adapt the solutions to your needs, as well as operational burden in continuing to maintain them. Vendors may have already put this effort into their offerings and handle the regular maintenance, which is part of the software expense. For the security architecture components we’ve outlined, we’ve gathered some of the OSS options where they are available. They may be a way for you to try a type of technology before committing to a purchase.

As with any selection and implementation of a security or nonsecurity tool, Gartner recommends a proper proof-of-concept and evaluation phase in your project. Gartner has heard from numerous clients that have taken the BYO approach that there have been cases where the controls ultimately do not scale as attackers and attacks ramp up in sophistication. If your organization is facing or will face more advanced attackers seeking to exploit or abuse applications, it is highly recommended you look at the vendor capabilities.

Some issues to be aware of with OSS/BYO options (see Table 2):

■ Tools may offer only basic functionality, such as basic rate limiting and IP address blocking. It may be easy to recreate this type of functionality in-house with existing network capabilities, such as ADCs, network load-balancing services or firewalls.

Gartner, Inc. | G00383318 Page 37 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

■ Sophisticated countermeasures are difficult to replicate and may need to be highly customized for your environment, requiring development, operational and security resources.

■ Configuration and integration are typically more complex, and in some cases are more cloud- centric.

■ Some options exist as both a feature-limited “free” version and a premium version that incurs cost, but adds more features and/or professional services. NGINX (an HTTP server and reverse proxy also positioned as an API gateway) and ModSecurity (a WAF) are good examples of the OSS being adapted into commercial offerings.

■ Cloud service providers (CSPs) may provide API gateways, API management and WAFs. These are sometimes built on OSS and then customized by the CSP. They typically require an additional expense on top of the standard instance use.

Page 38 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Table 2. Architecture Components and Possible OSS or BYO Options

Technology OSS or BYO Option

For Layer 7, reference the WAF section below. Sufficient CDN or CSC capability is DoS protection required to mitigate volumetric DDoS and is not in scope for OSS.

■ API Umbrella

■ Mashape Kong

API gateway ■ nginx

■ OpenResty

■ Tyk

■ Guardsquare ProGuard (obfuscation only; full capability requires DexGuard or Application shielding iXGuard)

■ AppConfig Community (facilitates integration with EMM/MAM or SSO) Application wrapping ■ Data Theorem TrustKit (cert pinning only)

Bot mitigation via CAPTCHA ■ Google reCAPTCHA

■ LinOTP Bot mitigation via MFA and/or OOB ■ privacyIDEA

■ Contrast Community Edition for Java (one app only)

RASP ■ Hdiv Community (feature-limited)

■ OWASP AppSensor

■ Apache Shiro

■ OWASP CSRFGuard

SDK ■ OWASP Java Encoder

■ OWASP Java HTML Sanitizer

■ Spring Security (framework)

■ ModSecurity

WAF ■ NGINX Plus (see Note)

■ OpenResty

Note: The solution is a premium offering and incurs a cost.

Source: Gartner (April 2019)

Gartner, Inc. | G00383318 Page 39 of 41

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

Gartner Recommended Reading Some documents may not be available as part of your current Gartner subscription.

“Selecting the Right API Gateway to Protect Your APIs and Microservices”

“Critical Capabilities for Full Life Cycle API Management”

“Magic Quadrant for Full Life Cycle API Management”

“Solution Comparison for Cloud-Based Web Application Firewall Services”

“Market Guide for Application Shielding”

“Defining Cloud Web Application and API Protection Services”

“How to Integrate Application Security Testing Into a Software Development Life Cycle”

“A Guidance Framework for Establishing and Maturing an Application Security Program”

“Magic Quadrant for Web Application Firewalls”

“Modern Identity and APIs: Mobile, OpenID Connect, OAuth, JSON and REST”

Page 40 of 41 Gartner, Inc. | G00383318

This research note is restricted to the personal use of [email protected]. This research note is restricted to the personal use of [email protected].

GARTNER HEADQUARTERS

Corporate Headquarters 56 Top Gallant Road Stamford, CT 06902-7700 USA +1 203 964 0096

Regional Headquarters AUSTRALIA BRAZIL JAPAN UNITED KINGDOM

For a complete list of worldwide locations, visit http://www.gartner.com/technology/about.jsp

© 2019 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. and its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior written permission. It consists of the opinions of Gartner's research organization, which should not be construed as statements of fact. While the information contained in this publication has been obtained from sources believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner research may address legal and financial issues, Gartner does not provide legal or investment advice and its research should not be construed or used as such. Your access and use of this publication are governed by Gartner Usage Policy. Gartner prides itself on its reputation for independence and objectivity. Its research is produced independently by its research organization without input or influence from any third party. For further information, see "Guiding Principles on Independence and Objectivity."

Gartner, Inc. | G00383318 Page 41 of 41

This research note is restricted to the personal use of [email protected].