BLOG | NGINX

Automate Security with F5 NGINX App Protect and F5 NGINX Plus to Reduce the Cost of Breaches

Thelen Blum Thumbnail
Thelen Blum
Published July 07, 2022
Matthieu Dierick Thumbnail
Matthieu Dierick
Published July 07, 2022

It might surprise you to learn that the money you spend on improving your security posture with automation and artificial intelligence (AI) ends up saving you much greater amounts of money. In its Cost of a Data Breach 2021 Report, the IBM Security team reveals that a security breach costs organizations without security automation and AI a whopping 80% more on average than organizations with fully deployed automation and AI – $6.71 million versus $2.90 million, a difference of $3.81 million. By prioritizing security automation and AI, organizations can faster identify and contain a breach, saving both money and time.

Bar chart showing average cost of a data breach by security automation deployment level
Data breaches cost organizations without security automation and AI millions more
(Source: Cost of a Data Breach 2021 Report)

As you integrate security into your CI/CD pipeline, however, it is important not to overload your tools. The fewer times you inspect traffic, the less latency you introduce. The business corollary is that technical complexity is the enemy of agility.

At F5 NGINX, we offer a security platform that is unique in its seamless integration and ability to help teams “shift security left” during the software development lifecycle. When organizations integrate “security as code” into their CI/CD pipeline, they enable security automation and AI, leading to the huge savings described by IBM. With security built into each stage of application and API development, configuration and security policy files are consumed as code and your SecOps team can create and maintain a declarative security policy for DevOps to use when building apps. These same policies can be repeatedly applied to new apps, thereby automating your security into the CI/CD pipeline.

Let’s peel back the onion and look at three phases of traffic processing where F5 NGINX App Protect and F5 NGINX Plus help you automate security protections:

  • Phase 1 – F5 NGINX App Protect DoS detects and defends against denial-of-service (DoS) attacks
  • Phase 2 – F5 NGINX App Protect WAF protects against OWASP Top 10 attacks and malicious bots
  • Phase 3 – F5 NGINX Plus authenticates app and API clients and enforces authorization requirements using native features and integrations with third‑party, single sign‑on (SSO) solutions
Diagram of three-phase security solution for efficient application traffic management to block illegitimate traffic and automate security, using NGINX App Protect DoS and WAF plus NGINX Plus
A three-phase security solution for efficient application traffic management to block illegitimate traffic and automate security, saving time and money

This three-part security solution saves you money in two ways, especially in a public cloud environment:

  1. Only legitimate traffic reaches your apps because NGINX App Protect DoS filters out traffic from DoS attacks and then NGINX App Protect WAF eliminates multiple attack vectors like the OWASP Top 10.
  2. NGINX Plus’s highly efficient, event-driven design means it can process huge numbers of requests per second with low CPU consumption. Processing only legitimate application traffic on a highly efficient platform requires significantly fewer compute resources, saving you time and money and ensuring protection against multiple attack vectors without overwhelming your tools.

If you are currently using F5 BIG-IP Advanced WAF to secure apps running in your data center, it is straightforward to add NGINX Plus as an Ingress controller for Kubernetes with NGINX App Protect Dos and WAF as a comprehensive solution to scale and secure your modern applications and orchestrate Kubernetes apps in the cloud. Using F5’s security-as-code approach, you can define infrastructure and security policy controls as code via a declarative API or declarative JSON‑formatted definitions in a file, and you can convert BIG‑IP XML files into JSON files as well. Your policies – the standard corporate security controls owned and maintained by SecOps – can reside in a code repository from which they are fetched and integrated into your development pipeline just like any other piece of code. This approach helps DevOps and SecOps bridge operational gaps and bring apps to market faster with lower cost and better security.

F5 incorporates WAF policy construction and baselining into the development process, an important part of “shifting security left” in the application development pipeline and automating application deployment.

Visibility tools in BIG‑IP and NGINX complement one another and enable SecOps to bake automation processes early into your DevOps lifecycle. BIG‑IP allows teams to convert XML files into JSON files used by NGINX to maintain your consistent security policies. NGINX allows teams to fine‑tune apps already in place, while bringing modern app security automation to help offset future breaches and the cost of those potential attacks.

Phase 1: NGINX App Protect DoS Defends Against DoS Attacks

The first stop on our secured traffic management journey is weeding out denial-of-service (DoS) attacks. Shutting this abuse down at the outset is a necessary first line of defense.

We have previously noted that attackers are increasingly switching from traditional volumetric attacks to using HTTP and HTTPS requests or API calls to attack at Layer 7. Why? They are following the path of least resistance. Infrastructure engineers have spent years building effective defenses against Layer 3 and Layer 4 attacks, making them easier to block and less likely to be successful. Layer 7 attacks can bypass these traditional defenses.

Not all DoS attacks are volumetric. Attacks designed to consume server resources through “low and slow” methods like Slow POST or Slowloris can be easily hidden in legitimate traffic. And while open source HTTP/2 remote procedure call frameworks like gRPC provide the speed and flexibility needed for modern apps, their characteristically open nature potentially makes them more vulnerable to DoS attacks than proprietary protocols.

Unlike traditional DoS protections, NGINX App Protect DoS detects today’s attacks by leveraging automated user and site behavior analysis, proactive health checks, and no‑touch configuration. It is a low‑latency solution to stopping common attacks including HTTP GET flood, HTTP POST flood, Slowloris, Slow read, and Slow POST.

To combat these attacks, SecOps and DevOps teams need to integrate “security as code” automation into their CI/CD workflow – part of the shift‑left mindset. NGINX App Protect DoS enables this. It secures modern, distributed apps and APIs with advanced protection from DoS threats and helps align the sometimes‑clashing priorities of SecOps and DevOps by facilitating this model with a lightweight software package, continuous threat mitigation feedback loop, and integration with familiar DevOps tools via RESTful APIs.

NGINX App Protect DoS integrates the machine learning (ML) technology that the IBM Security report highlights as key to significant cost savings. It analyzes client behavior and application health to model normal traffic patterns, uses unique algorithms to create a dynamic statistical model that provides the most accurate protections, and deploys dynamic signatures to automatically mitigate attacks. It also continuously measures mitigation effectiveness and adapts to changing behavior or health conditions. These features enable NGINX App Protect DoS to block DoS attacks where each attacking request looks completely legal, and a single attacker might even generate less traffic than the average legitimate user.

Diagram depicting eight types of attacks blocked by NGINX App Protect WAF and DoS
Security Solution Phase 1 and Phase 2: Application security with efficient traffic processing using
NGINX App Protect DoS and WAF

Phase 2: NGINX App Protect WAF Protects Against the OWASP Top Ten

While DoS protection clearly stops malicious traffic from entering your infrastructure, attacks can still make their way through. That is why you need a web application firewall (WAF) for the next phase of successful defense, where it focuses on traffic from bad actors that is masked as legitimate.

Lightweight and with high performance, NGINX App Protect WAF provides comprehensive security protection that inspects responses, enforces HTTP protocol compliance, detects evasion techniques, masks credit card numbers and other sensitive personal information with Data Guard, and checks for disallowed metacharacters and file types, malformed JSON and XML, and sensitive parameters. It also protects against the updated OWASP Top 10:

It is no surprise that cyberattacks against OWASP Top 10 vulnerabilities such as A03:2021 Injection remain popular. In July 2021, the open source e‑commerce site WooCommerce announced that many of its plug‑ins were vulnerable to SQL injection, and several attacks were occurring at that time. With businesses and customers operating primarily online, it makes sense that attackers focus on web‑based apps, which are often complex, composed of microservices, and span distributed environments with many APIs communicating with one another, increasing the number of endpoints vulnerable to exploitation.

Modern attacks also shift and adapt quickly. This is where AI comes in, and why IBM noted its importance. As in NGINX App Protect DoS, the rich ML system in NGINX App Protect WAF makes it easy for Platform Ops, DevOps, and SecOps teams to share attack trends and data. One new capability – the Adaptive Violation Rating feature – will further leverage ML by detecting when an application’s behavior changes. With this ML capability, NGINX App Protect WAF constantly assesses predictive behavior for each application. Based on this learning, it can enable client requests that otherwise would be blocked, lowering an app’s violation rating score and significantly reducing false positives for a better user experience with lower management costs.

NGINX App Protect WAF also provides bot protection. Today, nearly 50% of Internet traffic comes from bots. By eliminating known malicious traffic up front, NGINX App Protect WAF can quickly block bot traffic using its Bot Signature database.

Introducing WAF as a security layer early in your CI/CD pipeline helps mitigate security risk. Because NGINX App Protect WAF is CI/CD‑friendly, you can bake in and automate security as code early in your application development process. With early security awareness and the right collaboration among teams, you also eliminate bottlenecks like delivery risk. Multi‑stage DoS and WAF protection creates many points of inspection, giving Security teams visibility into app usage and App teams knowledge of how they are being maintained.

Phase 3: NGINX Plus Authenticates and Authorizes App and API Clients

Even after NGINX App Protect Dos and NGINX App Protect WAF weed out malicious traffic, you still need to verify that clients are legitimate and are authorized to access the resources they are requesting. That is where NGINX Plus enters the picture, handling authentication and authorization and then routing requests to the appropriate servers. By deploying NGINX Plus as an API gateway, you can provide one consistent entry point for multiple APIs and, again, simplify your stack.

Authentication and authorization can also be automated with single sign‑on (SSO) to enable DevOps teams to maintain their desired agility. NGINX Plus supports OpenID Connect (OIDC), an identity layer atop the OAuth 2.0 protocol. In the NGINX docs, we explain how to use OIDC to enable SSO for applications proxied by NGINX Plus.

Security Solution Phase 3: Authentication and authorization using NGINX Plus and OAuth 2.0/OIDC IdP‑compliant examples for SSO

Given their characteristic open nature, APIs are vulnerable targets. In their annual report, Gartner Research predicted that APIs would become the most common attack vector during 2022, causing countless data breaches for enterprise web apps. That prediction rings true as we make our way through 2022 and observe the API attack surface continuing to grow across organizations.

The API Authentication Incidents: 2020 Application Protection Report from F5 Labs highlights three common reasons for API incidents:

  1. No Authentication at API Endpoints
  2. Broken API Authentication
  3. Broken API Authorization

No Authentication at API Endpoints

When you implement authentication of API traffic, clients that successfully prove their identity receive a token from a trusted identity provider. The client then presents the access token with each HTTP request. Before the request is passed to the application, NGINX Plus ensures the authentication and authorization of the client by validating the token and extracting identity and other data (group membership, for example) encoded in the token. Assuming the token is validated and the client is authorized to access the resource, the request is passed to the application server. There are several methods to accomplish this validation, but OpenID Connect (built on the OAuth 2.0 protocol) is a popular way to enable third‑party authentication of API requests.

However, many APIs on the market are unprotected at the authentication layer. In 2021, interactive fitness platform Peloton was revealed to have a leaky API. A security researcher discovered it was possible to make unauthenticated requests to Peloton’s API, easily retrieving user data without authentication. While Peloton fixed the code before any major breach, this mishap highlights how a monolithic approach to security does not consider the inherent multiplicity of API structures and the consequent need for agility in defending them.

Broken API Authentication

APIs are designed for connecting computer to computer, so many DevOps teams assume humans do not communicate with the API endpoint. One example in the F5 Labs report involves a researcher who chained together several API requests to “earn” hundreds of thousands of dollars in credits on a mobile app. The app continuously generated tokens designed to prevent abuse, but did not set expiration dates on them, allowing them to be used over and over again.

If you don’t properly validate API authentication tokens, attackers can exploit API vulnerabilities. If this type of vulnerability is discovered by a bad actor, rather than a researcher, it can compromise an entire business.

Broken API Authorization

Unsuccessful API authentication naturally leads to broken API authorization. The F5 Labs reports also describes an incident where a bug in the operating system allowed malicious HTTP requests to the API, giving bad actors easy access to authorization tokens. Once the attackers acquired this authorization token, they had administrator permissions.

NGINX offers several approaches for protecting APIs and authenticating API clients. For more information, see the documentation for IP address‑based access control lists (ACLs), digital certificate authentication, and HTTP Basic authentication. Additionally, NGINX Plus natively supports the validation of JSON Web Tokens (JWTs) for API authentication. Learn more in Authenticating API Clients with JWT and NGINX Plus on our blog.

Get Started Today

Automating security makes it everyone’s responsibility. By prioritizing security automation, your organization can build more reliable apps, mitigate risk, reduce OpEx, and accelerate release velocity. This means your microservices, apps, and APIs get agile security that is scalable and fast enough to keep pace with today’s competition.

This three‑phase security structure also offers the best flow because you do not want to bog down your WAF inspecting traffic from a DoS attack or waste valuable resources trying to authenticate and authorize malicious actors. By eliminating the easily identified attacks early, you can save time, money, and accelerate your app performance.

Ready to try NGINX Plus and NGINX App Protect for yourself? Start a 30-day free trial today or contact us to discuss your use cases.


"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."