Cloud computing was not designed for security, although organizations such as Cloud Security Alliance (CSA) and Open Web Application Security Project (OWASP) are making great strides in helping the industry solve the myriad security problems confronting cloud computing. The benchmark guidelines established by the CSA in the document, Guidance for Critical Areas of Focus in Cloud Computing, are a great first step. This article is intended to pick up where the CSA guide left off in terms of defining what a distributed Web application firewall (dWAF) should look like in order to meet the standards set within the CSA document.
Alex Meisel is the CTO of Art of Defence GmbH, member of OWASP and Cloud Security Alliance. Alex’s core focus is Web application security.
In order to accurately outline how a dWAF is possible while maintaining all the benefits of a completely virtualized environment – reduced IT overhead, flexible footprint management, virtually unlimited scalability – a brief overview of cloud technology is needed. Far more than simply maximizing current hardware resources to benefit from unused CPU power, today there are three main technologies available in a cloud that provide the backbone for real productivity gains and compelling business services for companies that don’t want to invest in the hardware scaling burdens common today.
Software as a service (SaaS) offers users virtualized software through a thin client, usually any standard Web browser. The benefit for users is access to software without any of the headaches of owning the programs – scaling and resources are taking care of, and patching and upgrades are managed.
Platform as a service (PaaS) provides users with virtual databases, storage and programming languages with which custom applications can be built. This service provides nearly unlimited resources behind the platform and allows customers to scale throughout the lifetime of the application. It is an effective solution for companies ranging from the very small to those serving millions of customers. The customer does not worry about the infrastructure needed to run the services and is billed in per usage model.
Infrastructure as a service (IaaS) allows users access to virtually unlimited resources to build and manage their own virtual network. Customers can commission and decommission virtual resources depending on their need. The most obvious benefit is that there is no end-of-life for hardware anymore for the customers. The providers move them according to their service level from hardware to hardware without any downtime.
The common user benefit of services available through a cloud is access to key resources via the Internet, which provides an incredible degree of scaling without the need to invest in expensive hardware infrastructure.
Cloud Applications Are Highly Exposed to Threats
Accessing cloud technologies requires a thin client, and the world’s most commonly used thin client for this purpose is a Web browser. This means the vast majority of all applications on the Internet have some kind of Web and/or application server on which the business logic is implemented. Currently, most of the money spent on security goes into firewalls and antivirus solutions, but in the last 10 years the typical target for attacks has shifted from the network layer to the application layer because the operating systems and services available to the general public were cut down. As a result, it is now easier to target the application logic or framework of an application than the actual server behind the hardened network perimeter. Applications are mostly developed by the businesses themselves and not every developer considers security the highest priority, which leads to a wide variety of problems.
The IBM X-Force® 2008 Annual Report highlights that Web application vulnerabilities are the Achilles’ heel for corporate IT security. The impact of not being able to secure these vulnerabilities is far reaching.
Further, attack vectors increase exponentially in correlation with the mainstream adoption of cloud computing. Their increase is dictated by hosting and delivering infrastructure, platform and software. Establishing a comprehensive patch management system is the common solution offered by most in the industry, however, in practice this approach has proved very difficult and costly. Typical Web applications are built on open source components, by third parties, who rely on Web frameworks. This approach has the obvious benefits of interoperability and shortened development time, however, patching becomes exponentially more difficult. A flaw in one piece of open source code must be patched for each instance it is used throughout each application in which it is used. In a cloud setting, this becomes a very large issue.
Applications developed specifically for a cloud are often very complex, designed for access speed, scalability and flexibility for third-party development through an open API. For example, Salesforce.com, Google Docs, MySpace, Facebook and Twitter, are all prime examples. These ‘as a Service’ applications are developed two ways today: by moving on-premise applications to a cloud, and by developing and operating applications directly in a cloud.
Applications that are forced out of the internal company network and into a cloud carry the risks of exposing protected software to Web threats it was not designed to combat. Common security threats include injection attacks, cross site scripting or cross site request forgery.
There are a variety of services available for developing in a cloud, such as MS Azure Services, Google App Engine or Amazon EC2. There are many security challenges involved in developing Web applications in a cloud. For example, parameter validation, session management and access control are 'hotspots' for attackers. Developers not trained in those three fields of application development will most definitely create/develop applications that have security problems.
Why a Traditional Web Application Firewall Will Not Work
In a cloud, the infrastructure and the services are shared between customers, meaning one set of hardware is used by many business, organizations and even individuals. Each of these cloud operator customers adds a unique layer of policy settings, use cases and administrative enforcement requirements. For the cloud or service provider, security quickly becomes very complex. The average provider may have 10,000 customers subscribing to its service, each with varied policy settings for individual divisions within the company. The service provider now has to manage an nth degree of application filter settings.
Currently, Web application firewalls (WAF) and other security solutions are restricted to hardware appliances, which creates a serious bottleneck for cloud service providers. Dedicated hardware boxes simply don't allow for reasonably scalable levels of multiple administrators’ duties within a box’s singular security policy mechanism. Ironically, in addition to the traditional network hardware, cloud service providers are forced to have a rack full of dedicated WAF machines – one per customer – that take up space and eat up resources. Security becomes counter to the efficiency promises of a fully virtualized environment. This cost is passed on to customers, increasing adoption barriers to mainstream cloud computing.
In an ideal world, applications would be designed from the ground up to meet the rigors of a virtualized world, integrating security measures directly into the applications and thus solving a core problem with current cloud computing. Until the industry reaches this ideal), traditional Web application firewall boxes are preventing the industry from reaching the full potential of a cloud computing.
Defining the Distributed Web Application Firewall (dWAF) for Cloud Protection
Web application security in a cloud has to be scalable, flexible, virtual and easy to manage.
A WAF must escape hardware limitations and be able to dynamically scale across CPU, computer, server rack and data center boundaries, customized to the demands of individual customers. Resource consumption of this new distributed WAF must be minimal and remain tied to detection/prevention use instances rather than consuming increasingly high levels of CPU resources. Clouds come in all sizes and shapes, so WAFs must as well.
The dWAF must be able to live in a wide variety of components to be effective without adding undue complexity for cloud service providers. Today’s providers are using a variety of traditional and virtual technologies to operate their clouds, so the ideal dWAF should accommodate this mixed environment and be available as a virtual software appliance, a plug-in, SaaS or be able to integrate with existing hardware. Flexibility with minimal disruption to the existing network is central.
A Web-based user interface must allow customers to easily administrate their applications. Configuration should be based on the applications under protection, not defined by a singular host, allowing far more granular settings for each application. Ruleset configuration must be supported by setup wizards. Statistics, logging and reporting has to be intuitive and easy to use and must also integrate seamlessly into other systems. Most importantly for a dWAF, multi-administrator privileges must be made available and flexible enough to effectively manage widely divergent policy enforcement schemes. Cloud providers should look for a set of core protections.
Detection and Protection
Foundational security using black, white and grey listings for application requests and responses must be possible. To make sure pre-set policy enforcements are not activated or deactivated without approval from an administrator, deployment and policy refinement through establishing rulesets must be possible in a shadow monitoring or detection-only mode. Once the shadow monitoring ruleset is stable, only then should it be allowed to deploy in an enforcement mode on the dWAF. This allows complete transparency for the administrator into the real-world effect of this ruleset, while at the same time allowing layered rulesets to be tested without compromising existing policy enforcement. Avoiding false positives and relaxed established defenses is essential for a real-world, usable dWAF in a cloud.
Automated learning and ruleset suggestions based on intelligent algorithms or recommendations from a static source code analyzer or Web vulnerability scanner are also desirable from a manageability view. Again, this only holds true if the administrator retains full control over activation/deactivation of each ruleset. Without this control, wanted traffic may become blocked and policy settings would become compromised.
Application Shielding
Pro-active security functions are highly recommended to reinforce any application in a cloud. Detection is simply not enough for today’s Web application security. Features like transparent secure session management, URL encryption and form-field virtualization will provide strong deterrence to attack, while saving application development and deployment time. These features are effective because session management, URL encryption and form-field virtualization is done at the dWAF level and not in the application itself.
An authentication framework support that enables businesses to consolidate their applications under one management schema is also desirable for a dWAF. This enables users to handle the authentication in front of their applications rather than behind, which adds another perimeter of security. A consolidation of all applications with dedicated rights-management ability is also a strong usability function that will make an administrator’s life easier.
Integration with Existing Technology
Avoiding vendor lock-in is a common best practice for both networking and application security. Any technology that is added to an infrastructure, platform or application itself must connect as seamlessly as possible with existing technology. Security is all about layering technologies to create the best possible protection, so a dWAF must communicate freely between a security incident and the event management system (SIEMs).
No comments:
Post a Comment