WAF is No Longer Enough: Exploring Four Pillars of Web Security for AWS

In today's digital landscape, web security is of utmost importance for businesses relying on web applications to serve customers and generate revenue.

Web Application Firewalls (WAFs) have long been the primary security solution for shielding web applications from malicious attacks. However, today’s evolving threat landscape demands a more comprehensive approach. While WAFs excel at inspecting and filtering hostile HTTP requests, they may not be effective against more sophisticated and targeted attacks. To ensure full web security, additional measures are required to complement the capabilities of a WAF.

In this article, we discuss the four pillars of robust web security, going beyond WAF to include DDoS Protection, API Security, and Bot Management. We explore the strengths and weaknesses of each one, which will demonstrate why a robust strategy includes all four.

Content Overview

• Using AWS as the example
• Pillar 1: Web Application Firewall (WAF)
• Pillar 2: DDoS Protection
• Pillar 3: API Security
• Pillar 4: Bot Management

Using AWS as the example

To illustrate the concepts in this article, we will focus on organizations using Amazon Web Services (AWS), although the same concepts also apply to Google Cloud and Microsoft Azure.

Pillar 1: Web Application Firewall (WAF)

Why it’s important: As noted above, a WAF is a critical component of web security, designed to inspect and filter HTTP/HTTPS traffic to identify and block malicious requests. WAFs play a crucial role in protecting against common web application attacks, such as SQL injection and cross-site scripting (XSS).

Availability on AWS: Amazon offers a native WAF service (AWS WAF), which allows organizations to create custom rules and policies for application-layer security. Many third-party WAFs can also be used to filter incoming requests for AWS workloads; a few of these can even run natively within AWS environments.

Why it’s not enough: While AWS WAF provides a solid foundation for web application security, it has certain limitations. First, it primarily focuses on known attack patterns, which means it may not be effective against zero-day attacks or emerging threats. Second, WAFs are designed to identify threats based on hostile requests, but many types of attacks are based on requests that appear benign. Third, as with many WAFs, AWS WAF requires users to create and maintain their own security policies and rulesets, which can be challenging.

Addressing its limitations: Organizations should consider augmenting AWS WAF with additional security measures (besides the other pillars described below). Some third-party WAFs integrate threat intelligence feeds that can provide real-time threat data and proactive defense mechanisms. This enables organizations to stay ahead of emerging threats and strengthen their defenses against evolving attack vectors.

Furthermore, implementing advanced behavioral analysis and machine learning algorithms can enhance WAF capabilities by detecting anomalies and identifying new attack patterns. By leveraging these technologies, organizations can improve the accuracy and effectiveness of their WAF, thereby bolstering their overall web application security.

Lastly, some third-party WAFs are available as fully managed web application firewall solutions. This relieves client organizations of the responsibility to create and maintain their own security policies (which requires significant time and expertise) because the vendor does it for them.

Pillar 2: DDoS Protection

Why it’s important: __Distributed Denial of Service (DDoS) attacks __pose a significant threat to web applications, with the potential of overwhelming servers and disrupting service availability. DDoS extortion is a popular tactic among hackers and can be especially effective (for the attackers) during times when the victims would normally receive high volumes of traffic and revenue.

Availability on AWS: AWS provides built-in DDoS protection through AWS Shield, which defends against most common and large-scale volumetric attacks.

Why it’s not enough: AWS Shield Standard is free, but it doesn’t provide full protection against DDoS (e.g., it doesn’t protect against layer-7 attacks). Most organizations will need to buy AWS Shield Advanced instead, but it can be expensive (at a base fee of $3,000 per month plus data fees, and a one-year commitment). Even then, it has trouble protecting APIs, and except for AWS Route 53-hosted zones, AWS Shield does not protect resources in hybrid/multi-cloud deployments.

Lastly, AWS Shield is meant to mitigate straightforward volumetric assaults. It is not designed to defend against more sophisticated tactics such as yo-yo DDoS attacks, which are designed to inflict maximum financial damage on the victim while minimizing the resources expended by the attacker.

Addressing its limitations: Organizations can consider augmenting or replacing AWS Shield with a DDoS mitigation solution that leverages advanced detection algorithms and traffic analysis. These solutions provide real-time monitoring and mitigation, enabling proactive identification and neutralization of evolving DDoS threats. They often will have lower cost structures (especially the all-in-one solutions that include DDoS protection as part of a comprehensive platform), and most will support hybrid and multi-cloud architectures.

Also, as was discussed above, a fully managed solution can be helpful in defeating sophisticated attacks such as human-orchestrated yo-yos, resource depletion (a tactic that can be used against serverless), and other strategies, because the vendor’s security team will monitor and respond to the incidents as they occur.

Pillar 3: API Security

Why it’s important: APIs have become a crucial component for seamless integration and data exchange for many reasons, including the popularity of cloud computing, the prevalence of microservice architectures, the increasing number of mobile applications, and others. As API traffic has grown, securing APIs against hostile activity has become vitally important.

Availability on AWS: AWS offers services such as AWS Identity and Access Management (IAM) and Amazon API Gateway. IAM enables organizations to manage access to AWS resources, while API Gateway provides authentication, authorization, and traffic management capabilities.

Why it’s not enough: To protect their APIs, AWS users are expected to use AWS WAF together with API Gateway. This means that AWS WAF’s limitations are also applicable to API security. In fact, there are actually more limitations when used in this context. For example, in certain situations, AWS WAF uses browser challenges and CAPTCHAs to verify incoming requests, but these can’t be applied to API traffic.

Addressing its limitations: AWS users can augment AWS’ native security capabilities with other tools. Some third-party security solutions include extensive features for protecting API traffic with equal effectiveness as web application traffic, not only for filtering hostile requests but also in related capacities such as granular access controls and comprehensive traffic visibility and logging. Some go even further and leverage opportunities for additional protection in certain situations, e.g. by providing an SDK to add extra hardening for mobile application traffic.

Pillar 4: Bot Management

Why it’s important: The prevalence of bots on the web presents a significant challenge for organizations. While some bots serve legitimate purposes, others are deployed for malicious activities such as account takeover, content scraping, and credential stuffing. On average, about 38 percent of total web traffic consists of hostile bots.

Traditional web security technologies such as WAFs are not designed to detect hostile bots, since most forms of automated traffic masquerade as legitimate users. Usually, the individual requests appear benign (and thus, avoid filtering). Their malicious goals are only manifested in their collective actions. For example, inventory denial bots appear to be legitimate customers performing shopping activities; however, these “customers” never actually buy anything. Instead, they take actions that make inventory unavailable to legitimate customers (such as placing items in shopping carts, completing the initial steps of travel reservations, etc., but never consummating the transactions).

Availability on AWS: Amazon offers AWS WAF Bot Control, a managed rule set for AWS WAF.

Why it’s not enough: As an add-on to AWS WAF, Bot Control includes the same limitations as mentioned above. However, these issues are magnified when trying to exclude hostile bots from web applications and APIs, because, among all forms of web attack, the most complex and sophisticated ones are often waged by bots. For example, the lack of precision in AWS’ rate-limiting capabilities makes it difficult to completely block bots that are performing credential stuffing and other forms of ATO (account takeover) attacks. Incomplete or delayed traffic visibility can hinder customers from fully understanding bot activity in their web properties or from fine-tuning security policies to reduce False Negative and False Positive alarms. Having to write and maintain complicated security policies increases the potential for error. And so on.

Next, using Bot Control creates additional usage charges. When combined with the cost of AWS WAF, AWS Shield Advanced, AWS API Gateway, etc., customers can face monthly fees that are quite high.

Lastly, the basic (“Common”) tier of AWS Bot Control relies upon simplistic methods for identifying bot traffic (primarily the request’s User-Agent, and whether or not the IP address is blacklisted). Threat actors can easily evade detection that is based on these criteria. To get better bot detection, customer organizations must purchase the top (“Targeted Bots”) tier, which costs even more (but can still have difficulty identifying the latest generation of evasive bots).

Addressing its limitations: In general, hostile bot mitigation can be the most challenging aspect of maintaining a robust security posture. As such, of the four pillars discussed in this article, this is the one where overcoming the inherent limitations of AWS’ native tools is the most important.

Many third-party web security solutions include bot management capabilities that exceed those of Amazon Web Services. This isn’t surprising; AWS is in the business of selling access to cloud resources and provides security tools merely to encourage the consumption of those resources. Conversely, web security vendors are in the business of creating robust, effective security solutions.

When evaluating WAAP (web application and API protection) solutions in terms of bot management, the primary considerations are those which have already been discussed above. The best will enable customers to precisely define security policies, view and control their traffic in real time with full visibility, and leverage powerful technologies such as machine learning and behavioral analysis.

In addition, many organizations will require a full management option, so that they can have their cybersecurity defenses configured and maintained by a team of security professionals, rather than requiring in-house staff to perform this role.

Conclusion

While a Web Application Firewall is a critical component of web security, relying solely on a WAF is no longer sufficient in today's threat landscape. By embracing the four pillars of web security–WAF, DDoS Protection, API Security, and Bot Management– AWS users can establish a robust and multi-layered defense against a wide array of threats.

\While AWS provides some built-in security tools, It is crucial to understand their limitations and to complement them with external security measures tailored to specific threats. By adopting this comprehensive approach, organizations can effectively protect their AWS web applications and APIs, and mitigate risks in the modern threat environment.