Move Securely to the Cloud: WAF Requirements and Deployment Options

Moving to the cloud has become an overwhelmingly popular trend even among organizations that were at first reluctant to make the move. Wherever you are in your cloud migration plan, it can take time, sometimes years, and often starts with first moving peripheral workloads to the cloud while leaving the core business components (such as databases) in the physical data center. While the cloud aims to provide agility, save costs and provide other benefits, a primary concern is security—specifically whether the cloud can provide the same high level of security as the physical data center.
The good news is that securing web traffic in the cloud can be done—leading web application firewall (WAF) solutions that protect data and apps in physical data centers are also available in the cloud. Choosing an agile, yet powerful WAF is key to making the cloud environment as secure as the physical data center. In this post, we’ll discuss requirements and deployment options for evaluating a WAF for the cloud.

Web application attack types

To begin, let’s review common web application attacks WAF solutions are meant to protect against. Today’s primary web application threats can be grouped into four main categories:

• Application layer attacks: SQL injection and cross site scripting (XSS) are two common types of application layer attacks; successful past breaches feed more account takeover attacks, trying to extract more credentials and user information; mobile APIs still exposed with many vulnerabilities; and we witness steady stream of vulnerabilities from 3rd party components.
• Distributed denial of service (DDoS): a type of application layer attack; these attacks use bigger botnets, leveraging security vulnerabilities in Internet of Things (IoT) products; cheaper and stronger DDoS services are available for hire (DDoS as a Service).
• Ransom: end-point ransomware peaks; extortion is on the rise as attackers try to monetize the attacks.
• Insider attacks: malicious insiders (i.e. disgruntled employees) are a major threat; IoT devices increase careless/compromised risk.

Security organizations are required to mitigate these threats in the physical data center, and the threat landscape remains the same when moving to the cloud. But the security model changes. For the purposes of this post we’ll focus on application layer attacks.

The security model in the public cloud

The leading cloud vendors introduced what’s called a shared responsibility model for security in the cloud. Amazon states that AWS has “responsibility for security of the cloud”, while customers have “responsibility for security in the cloud”. The same model was also adopted by Microsoft Azure, Google Cloud and other cloud vendors. Simply put, shared responsibility means that the cloud vendors provide tools and services for securing the infrastructure (such as networking and compute machines), while the customer is responsible for things like network traffic protection and security of the data. For example, cloud vendors help to restrict access to the compute instances (AWS EC2/Azure VM/Google CE) on which the web server is deployed (by using security groups/firewalls and other methods); they also deny web traffic from accessing restricted ports by setting only the needed HTTP or HTTPS listeners in the public endpoints (usually the load balancer).
But public cloud vendors do not provide the necessary tools to fully protect against application vulnerabilities such as OWASP top 10 threats or automated attacks. It’s the customer’s responsibility to establish security measures that allow only authorized web traffic to enter their cloud-based data center – just like in the physical data center. Securing web traffic in physical data centers is typically done by a WAF and it can also be deployed in the public cloud as well.

×

Nov 26 Upcoming Webinar

The True Cost of API Insecurity and Bot Attacks in 2024

Register Now

Mitigating application layer attacks in the cloud

When choosing solutions to mitigate different web application threats, it is important to make sure that the right tools are used. The first mitigation layer is usually common for all attackers, such as denying access from badly-reputed sources (“malicious IPs”) and blocking requests based on predefined signatures. This layer could be useful against generic types of attacks, like a botnet attack looking for known vulnerabilities. The more targeted the attack is, the more fine-grained the tools required to mitigate it—as is the level of control required by the security team. When an attacker is trying to launch an attack tailored to a specific web service, a tool that provides customization is needed to block it.
An advanced and customizable WAF can be deployed within the private network and offer full control to the security administrator, including deployment topology and security configuration. A WAF that is deployed in the public cloud should support several key attributes:

• Scalability: As scalability is highly important in cloud environments, a WAF solution must also be able to scale, providing the ability to process more web traffic as the load grows. The WAF tier should scale independently of the web application tier, as sometimes low traffic that is hardly noticeable on the WAF may require massive backend computations. In that case, while additional resources may be required on the web servers, the WAF will not need to scale. Using a different load balancer for each tier can assist in independent scaling.
• High availability: In order to allow business continuity at all times the WAF must be highly available. Usually this means that the WAF stack needs to utilize the cloud native tools for high availability (for example, span over availability zones in AWS or be part of availability set in Azure).
• Automation: As cloud environments are often highly dynamic, the entire environment needs to be automated. Automation can be used to launch the environment, scale up and down, tune policies and handle maintenance operations. A WAF in a cloud environment needs to provide tools that facilitate automation. The automation can be orchestrated using native orchestration services (such as CloudFormation in AWS and ARM in Azure), or by other third-party tools (Puppet or Chef for example).
• Centralized management for hybrid deployment: Migration to the public cloud often happens over time and a hybrid deployment mode – in which some of the workload remains in the physical data center and some in the cloud – is very common. Operationally this raises the question of how to apply the same organizational security policies in both the physical data center and the cloud. A centralized management solution that can control WAFs in both locations is required.

Conclusion

Leaving the well-known and well-protected data center for the cloud is a big move, but it can be done securely—it just requires careful planning, finding the right tools, and the right architecture. Choosing an agile yet powerful WAF is a solid first step.
To learn more, read about Imperva WAF solutions for cloud security, get lessons learned on hybrid WAF deployments from Imperva’s CISO, and download our WAF Buyers Guide.