The Six Reasons DevSecOps Should Address Bot Management

In this age of digital competition, all companies are technology companies, and contemporary innovations have disrupted industries from finance to grocery to transportation. To win as a modern tech company requires innovating faster than the competition, and rapid innovation requires DevOps. DevOps is a collaboration between developers and IT operations that has sparked breakthroughs in the pace of product releases by applying Lean principles to software delivery. Despite the promise of DevOps, bot attacks and other security concerns—if not properly addressed—may prevent organizations from reaping the benefits. Fortunately, DevOps has given rise to DevSecOps, a role well positioned to take on security concerns, and particularly bot management, in the fast-paced world of DevOps.

In a DevOps culture, DevSecOps takes on responsibility for incorporating security into the continuous integration /continuous development (CI/CD) pipeline, ensuring rapid feedback to developers on security bugs, and continuously improving the integration of security into the technology value stream.

With its foundation in Lean manufacturing practices, DevOps emphasizes moving quality considerations earlier in the value stream to reduce failures downstream, where the cost of rework is greater; it is better to design quality into a product than discover flaws through inspection. As security is a critical element of quality, DevSecOps likewise engages in moving security to the left, making sure any gaps are planned for earlier in the workstream. The earlier tools such as Static Analysis Security Testing, Dynamic Analysis Security Testing, and vulnerability scans are run, the earlier developers get feedback, and the earlier bugs can be fixed.

And the more security is addressed in requirements gathering, design, and coding, the more effective the security controls will be. While these are foundational concepts of secure coding and the software development lifecycle (SDLC), these practices become ever more important in a DevOps environment because addressing security later would either impede rapid deployments or cause security risks.

Given the critical role of DevSecOps in securing the modern enterprise, it follows that bot management should be included among the responsibilities of that particular discipline. Not only is bot management essential to security and thus core to the mission of DevSecOps, but DevSecOps is also ideally positioned to ensure that organizations are well protected against malicious bots. So, as promised, here are the six reasons DevSecOps should address bot management:

1)   Bot protection is essential to security and data privacy

Bots are scripts that automate the sending of HTTP requests to applications and APIs. Criminals use bots to attack web and mobile apps in several types of attacks:

• Credential stuffing: Attackers test stolen credentials against logins to take over accounts.
• Fake account creation: Criminals create fake accounts to perform fraud such as social media influencing and money laundering. (See an F5 analysis on Twitter’s fake account problem.)
• Carding: Criminals validate stolen credit card data.
• Card cracking: Criminals identify security codes and missing start and expiry dates for stolen payment card data by trying different values.
• Stealing gift card balances and loyalty points: Criminals steal gift card balances and loyalty points, relying on the fact that users check these balances infrequently.
• Purchasing/Resale: Illicit brokers purchase goods on limited time offers for resale at higher prices.
• Inventory hoarding: Bots reserve goods and services but do not complete the purchase, making it appear that inventory is unavailable and preventing legitimate purchases.
• Scraping: Scraping bots extract data from apps, causing competitive disadvantage and slowing site performance.

For a comprehensive taxonomy of bot attacks, see the OWASP Automated Threat Handbook or this summary from Kyle Roberts.

Of all bot attacks, credential stuffing is particularly pernicious. The Global Privacy Assembly (GPA) has declared credential stuffing a global threat to data privacy. The GPA, which represents over 130 data protection and privacy regulators and enforcers, insists that bot management is now a necessary measure for data privacy, and thus mandatory for all business-to-consumer enterprises doing business online.

If DevSecOps is going to fulfill its mission of securing the organization and its customers, it is critical to solve the problem of malicious bots.

2)   Bots corrupt the telemetry that DevOps depends upon

According to the DevOps Handbook, telemetry is essential for predicting, diagnosing, and resolving problems in complex systems—that is, systems that are too big and too intertwined for any one person to understand how all the pieces fit together. For DevOps to succeed, telemetry should cover multiple layers including business metrics, feature usage, network performance, and infrastructure load so that a problem in one layer can be traced across the stack for the rapid identification of root causes.

Bots distort telemetry in a big way. Many customers of F5 Distributed Cloud Bot Defense discovered that most of their user accounts were fake and that bots accounted for over 95% of login traffic. In some cases, the bulk of an organization's infrastructure did nothing more than serve scraping bots.

Without the ability to distinguish human from bot, telemetry would become meaningless. Is a feature failing because of real users or bots? Why is the login success rate so variable? What caused a sudden spike in traffic to a particular application path? Bots drown out the signal in all their noise.

For DevOps to succeed, it needs meaningful telemetry, and making telemetry meaningful requires the ability to detect bots. DevSecOps can make a significant contribution to DevOps success by engaging in bot management, ensuring the integrity of the data so essential to DevOps.

3)   Bot protection is not code security nor exclusively a dev task

Unlike traditional vulnerabilities that developers can address through coding best practices and vulnerability testing, bot attacks mostly target legitimate functionality that an app must expose, such as login, forgot password, product checkout, and product pricing information. (F5's Dan Woods refers to these as inherent vulnerabilities in his interview on Pirate Radio.) While bot protection is essential to app security, it is not about secure coding and cannot be solved by developers alone. Bot protection falls into that space between developers and InfoSec, precisely the space DevSecOps occupies.

Because criminal organizations are well incentivized to develop bots that bypass detection, protecting against malicious bots is surprisingly difficult. CAPTCHA no longer works. CAPTCHA solving services using ML and human click farms make solving CAPTCHA fast and cheap. (See Dan Wood’s Tales of a Human CAPTCHA Solver.) Bots execute JavaScript to satisfy proofs of work, mimic real human behavior, introduce subtle randomness, and exploit proxy networks to disguise their origins through millions of valid residential IP addresses. And criminals retool bots within hours of detection. This sophistication and rapid evolution of bots means that the days of stopping bots through manual updates to WAF rules have long passed.

Forcing this level of effort onto dev personnel would prevent them from getting any features out the door. Pushing it onto the ops team to update WAF rules would burn up all their resources. Organizations need DevSecOps involved to integrate a bot management solution into the technology value stream.

4)   DevSecOps knows the app logic, which is essential to effective bot protection

While protecting against bots is not a purely dev task, neither is it a purely ops task in the traditional sense of ops; configuring bot protection requires detailed knowledge of the application, its requirements, design, and implementation.

Looking at the bot attack types listed above, which of these apply to your application? For each of these attack types, which path or API will the bots go after? For each of these paths, where is it possible to instrument signal collection to gather the data necessary to distinguish bots from humans?

In configuring bot protection for web, we at F5 refer to the protected paths as endpoints and the pages that require instrumentation as entry points. Picture a login. One web page may host the login form, which we’d call the entry point. And that form may post to a particular path, which we’d call the endpoint. Of course, it’s not always that simple. The login form may exist on many pages, and these forms might be posted to different paths.

It’s a similar story for mobile. Protecting mobile apps from bots generally requires the integration of an SDK for telemetry instrumentation. Determining which network requests need to include this telemetry requires knowledge of the app.

Given this app knowledge required for configuration, bot management is a good fit for DevSecOps, particularly as it makes sense to move this step to the left, in considering bot management during requirements and design phases.

5)   DevOps knows the infrastructure

Protecting against bots likewise requires an understanding of network infrastructure. Generally, bot protection will be provided via an API that gets called from a layer in the network, perhaps a CDN, a load balancer, an API gateway, an ingress controller, or an application platform. One of these layers will be configured to send relevant traffic to the bot management API to determine whether a request is from a human or bot.

Working with dev and ops, the DevSecOps team will have the broadest perspective on how to decide where to implement these API calls in a way that can be fully automated (as part of the CI/CD pipeline) and that offers optimal performance.

6)   DevSecOps knows where bot management should fit into the CI/CD pipeline

As organizations release new features through the technology value stream, bot defenses will need configuration updates, just as other security components such as the WAF do. The DevSecOps team is well positioned to determine where in the CI/CD pipeline this automated configuration update should take place.

This is more complex than it might initially appear, as bot protection could interfere with automated QA testing, which would be detected as a bot. There are multiple ways to resolve the problem, such as allow-listing the testing tools via headers or IP addresses or putting bot protections in place only after automated QA testing completes.

Most significantly, DevSecOps needs to work with dev and InfoSec to determine where bot protection is required and provide a way to make sure it’s in place as relevant features are released.

Wrapping it up

Organizations that provide consumer applications need to keep customers safe online, protecting their data privacy and financial security. In any organization pursuing competitive advantage through the rapid innovation made possible through DevOps, protecting customers requires DevSecOps so that security keeps up with the pace of releases. Among the responsibilities of DevSecOps, bot management is essential. Bot attacks put customer security at grave risk, and DevSecOps brings skills to the table that are very valuable for defending against malicious bots and empower organizations to securely embrace rapid innovation.

For further insights into the ROI of bot protection, see the Forrester Total Economic Impact Report. Learn more and schedule a conversation with an F5 bot expert at f5.com/bot-defense.