When NGINX released NGINX Controller 3.0, we explained that our guiding principle in developing the new version was “we can do better”. Our customers had told us over and over that the traditional infrastructure‑centric approach to traffic management and load balancing was often too slow, too complex, or too difficult for DevOps and Developer teams to use. So we introduced an application‑centric approach that makes it easier to deploy and manage apps. With Controller’s app‑centric approach and APIs, modern app teams can thrive because the infrastructure team can now offer traffic management and load balancing as a self‑service function to their DevOps and Developer teams. This ensures high availability and high performance of their apps, resulting in a great user experience for their customers.
Even with self‑service traffic management enabled by the Controller 3.0 Application Delivery Module, however, the user experience can still be bad if malicious attacks slow down the app or security vulnerabilities allow end‑user data to be stolen. Of course, security threats put the organization at risk as well. So, inspired again by “we can do better”, we have worked to create an app‑centric, self‑service approach to app protection, abstracting away the need for security expertise on the part of DevOps and Developer teams, the same way Controller App Delivery does for traffic management. That leaves the teams free to concentrate on what they do best: develop apps.
Why Do App Teams Resist Security?
We knew that a big part of how we can do better was to address the reasons DevOps and Developer teams (app teams) hesitate to add security protections to their apps, which include:
- Traditional security approaches don’t work for modern apps.
- Adding security degrades app performance.
- It’s not easy to integrate security into their workflows and toolchains.
- Waiting for the security team to implement security hurts productivity and slows time to market.
Let’s explore these challenges in more depth.
Traditional Security Doesn’t Work for Modern Apps
Many app‑protection solutions don’t work for modern apps. While most solutions might protect some apps, many of them still do not provide protection for API‑based or distributed apps. Not only do traditional solutions not use the appropriate protocols and payload types, in many cases their heavy use of resources means they don’t work in the less resource‑rich environments where distributed apps typically run. Plus, many app‑protection solutions only work in certain clouds – moving to a different cloud provider means starting all over again with a new solution.
Security Slows Down the App
Most app‑protection solutions slow down the app immensely, inevitably harming the user experience. Uh oh. To compensate, our customers have had to deploy and manage many instances of both apps and the protection solution to achieve the necessary level of performance.
Security Is Not Easy to Deploy
There are several reasons it’s not easy for Developer and DevOps teams to deploy app‑protection solutions along with their apps:
- The solutions are not designed to be deployed as part of automated continuous delivery pipelines.
- Integrating more tools takes time and resources, and increases pipeline complexity.
- App‑protection and app‑delivery solutions are usually distinct products, so app teams have to monitor security and performance separately.
- App teams need security expertise to deploy and operate them.
Adding Security Hurts Productivity and Time-to-Market
The biggest reason Developer and DevOps teams don’t want to bother with security is that they aren’t incentivized to! They are incentivized to deploy their apps quickly. Adding traditional app protection usually means asking the Security team to add a policy, tune it, and so on, all of which slows down time to market.
But Security Teams Have Needs Too
There are some app‑protection solutions that are relatively easy for DevOps and Developer teams to use, but they don’t necessarily meet the needs of the Security team, which must ensure that the app protection in place satisfies the organization’s security and governance standards. Security teams need centralized visibility into compliance and the threats the app‑protection tools are seeing. Perhaps the hardest thing for Security teams is knowing that even when security compliance is not being maintained they can’t stop apps from being deployed. That is a losing battle.
Introducing the NGINX Controller App Security Add-On for Application Delivery
With the introduction of the NGINX Controller App Security add‑on for Controller Application Delivery, we are addressing the aforementioned challenges for modern app teams. Controller App Security enables an app‑centric, self‑service way for DevOps and Developer teams to enable a web application firewall (WAF) for app protection and threat visibility. A WAF protects web apps from a variety of Layer 7 attacks by monitoring and filtering HTTP traffic to the apps. With Controller App Security, app teams can easily enable app protection, along with traffic management, when deploying their apps.
Controller App Security enables customers to balance developer productivity with operations and security compliance.
In its initial release, Controller App Security includes the capabilities discussed in the following sections.
Multi-Cloud, Self-Service, App-Centric App Protection
Customer infrastructure teams (Network Operations, Security Operations) can install NGINX App Protect as a module on NGINX Plus instances (the data plane) in various environments and clouds to provide WAF services. NGINX App Protect provides a powerful WAF protection enforcement engine in front of HTTP‑based apps. Then, NGINX Controller manages these instances.
With Controller App Security in place, app teams can share the data‑plane instances and enable WAF protection for their specific apps or APIs in a self‑service manner, without having to wait for infrastructure teams to perform setup and without impacting other teams’ apps. Turning on the WAF is a simple matter of adding just one parameter to the API call for enabling traffic management – no need to incorporate a separate new solution into the workflow. Similarly, app teams manage the WAF with the same declarative API and web interface they already use to control traffic management with Controller App Delivery.
Lightweight, High-Performance WAF
Controller App Security employs NGINX App Protect, running as a module on NGINX Plus, as the powerful app‑protection engine to enforce WAF policies for a wide variety of web apps, distributed apps, and APIs. Compared to other WAFs, NGINX App Protect is both high performance and resource efficient at runtime. Our enterprise customers’ Security teams trust NGINX App Protect because it’s based on the F5 WAF technology they’re already using to protect their most valuable applications.
Default Policy Focused on OWASP Top 10 Protection with Low False Positives
The default policy provided with Controller App Security focuses on protecting apps against:
- OWASP Top 10 vulnerabilities (including injection, cross‑site scripting, etc.)
- Malformed cookies, malformed JSON, etc.
- Attacks related to various HTTP RFC non‑compliance and evasion techniques
- Many more app‑protection checks
The default policy uses algorithms that are based on F5’s WAF and app‑protection expertise to reduce false positives.
With this default policy, Controller App Security makes it easy for DevOps and Developer teams to start enabling app protection without having to wait for Security teams to provide a custom policy.
GUI for Verifying App-Protection Compliance
Security teams can use the Controller web interface to verify that app protection has been enabled for each component for each app and whether it is operating in blocking or monitor‑only mode.
App-Centric Feedback Loop Visibility and Insights
DevOps and Developer teams get out-of-the-box app protection‑related metrics and visibility of rule‑violation events in the same way they already receive information about app performance – from the Controller Analytics API and web interface – and specifically for their app and its components (that is, URIs). This makes it easy to get feedback loop visibility about the app protection positioned in front of their app. The visibility and insights include:
-
WAF violation event log for requests, with details of observed violations
-
Top app URI targets and top types of attacks seen by the WAF
-
Outcome statistics for requests processed by the WAF (count of requests blocked or flagged with WAF violations), compared with previous periods to determine spikes for further investigation
- The metrics above and more can be forwarded to Splunk and Datadog (currently in beta)
App Protection Tuning
Controller App Security reveals which signatures may be causing false positives, so DevOps and Developer teams don’t have to wait for the Security team to perform WAF operations. The self‑service approach means DevOps and Developer teams own security for their app, while the Security team can still ensure compliance.
Summary
Controller App Security addresses the needs of DevOps, Developer, and Security teams. It provides trusted app protection and app‑layer threat visibility that can be standardized across HTTP‑based apps and APIs running in multi‑cloud environments (private, public, and hybrid cloud). Most importantly, it enables enterprise Security teams to provide an app‑centric, self‑service model for DevOps and Developer teams to easily add app protection to their apps. At the same time, Security teams maintain visibility into compliance.
Today, we take Controller to the next level again, providing the tools for our customers to successfully balance security with time to market. Controller App Security is a win for speed and a win for app security.
Try NGINX Controller App Security for yourself during a free 30‑day trial of NGINX Controller, NGINX Plus, and NGINX App Protect:
- At MyF5, create an account if you don’t already have one, and log in.
- On your MyF5 Dashboard page, click the Try NGINX Controller button.
For technical specifications and complete installation instructions, see the NGINX Controller documentation.