"Implementing Deny All Web Application Firewall was the most efficient and cost effective solution to comply with the PCI DSS Standard and to secure our growing number of web applications. Deny All WAF solution was the easiest to deploy, configure and replicate of the solutions we looked at. "

 

Petri Vuontela, Director, Customer systems at Aktia

Want to make your Web Applications PCI DSS-Compliant ?

 

Join our PCI DSS Expert for an educational webinar about WAF benefits and customer best practices.

DENY ALL WAF SOLUTION OFFERS ALL CAPABILITIES RECOMMENDED BY THE PCI SECURITY STANDARDS COUNCIL

Meet all applicable PCI DSS requirements pertaining to system components in the cardholder data environment.

React appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5.

Inspect web application input and respond (allow, block, and/or alert) based on active policy or rules, and log actions taken.

Prevent data leakage-meaning have the ability to inspect web application output and respond (allow, block, mask and/or alert) based on the active policy or rules, and log actions taken.

Enforce both positive and negative security models. The positive model ("white list") defines acceptable, permitted behaviour, input, data ranges, etc., and denies everything else. The negative model ("black list") defines what is NOT allowed; messages matching those signatures are blocked, and traffic not matching the signatures (not "black listed") is permitted.

Inspect web services messages, if web services are exposed to the public Internet. Typically this would include Simple Object Access Protocol (SOAP) and eXtensible Markup Language (XML), both document- and RPC-oriented models, in addition to HTTP.

Inspect any protocol (proprietary or standardized) or data construct proprietary or standardized) that is used to transmit data to or from a web application, when such protocols or data is not otherwise inspected at another point in the message flow.

Defend against threats that target the WAF itself.

Support SSL and⁄or TLS termination, or be positioned such that encrypted transmissions are decrypted before being inspected by the WAF. Encrypted data streams cannot be inspected unless SSL is terminated ahead of the inspection engine.

 

ADDITIONAL RECOMMENDED CAPABILITIES FOR CERTAIN ENVIRONMENTS

Prevent and/or detect session token tampering, for example by encrypting session cookies, hidden form fields or other data elements used for session state maintenance.

Automatically receive and apply dynamic signature updates from a vendor or other source. In the absence of this capability, there should be procedures in place to ensure frequent update of WAF signatures or other configuration settings.

Fail open (a device that has failed allows traffic to pass through uninspected) or fail closed (a device that has failed blocks all traffic), depending on active policy.

In certain environments, the WAF should support Secure Sockets Layer (SSL) client certificates and proxying client authentication via certificates. Many modern web applications use client SSL certificates to identify end users. Without this support, these applications cannot reside behind an application firewall. Many modern application firewalls will integrate with Lightweight Directory Access Protocol or other user directories and can even perform initial authentication on behalf of the underlying application.

Some ecommerce applications may require FIPS hardware key store support.If this is a consideration in your environment, make sure that the WAF vendor supports this requirement in one of their systems and be aware that this feature may drastically increase the cost of the solution.