Radware AppWall:

PCI 6.6 Compliance

White Paper

November 2008

Table of Contents

1.

General .............................................................................................................. 3

2.

PCI Compliance with Radware AppWall................................................................... 4

3.

2.1.

Addressing PCI 6.6 Requirements with AppWall ............................................................. 4

2.2.

Addressing PCI 6.5 Requirements with AppWall ............................................................. 8

Addressing OWASP Top Ten with AppWall ............................................................... 8

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 2

1. General
.
The Payment Card Industry (PCI) Data Security Standard (DSS) was developed by the
major credit card companies as a guideline to help organizations that process card
payments prevent credit card fraud, hacking, and various other security issues. A
company that processes, stores, or transmits credit card numbers must be PCI DSS
compliant or they risk losing the ability to process credit card payments. Merchants and
Service Providers must validate compliance with an audit by a PCI DSS Qualified Security
Assessor (QSA) Company.
PCI DSS Requirement 6.6 provides two options that are intended to address common
threats to cardholder data, and ensure that input to Web Applications from untrusted
environments is inspected top to bottom.
The minimum vulnerabilities to consider are described in Requirement 6.5 in the PCI DSS
version 1 document. In the context of Requirement 6.6, an application firewall is a Web
Application Firewall (WAF), which is a security policy enforcement point deployed between
a Web Application and the client end-point.
This document details how Radwares AppWall Web Application Firewall addresses all
requirements and recommendations as detailed in the following documents:
1. Payment Card Industry (PCI), Data Security Standard, Version 1.1
2. Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls
Clarified.
The PCI DSS requirements and recommendations and how AppWall addresses them are
presented in tables that should assist you in assessing and comparing the capabilities of
the Radware solution.
Note: This paper is not intended to give an overview of AppWall as a whole product. A
detailed solution overview is available on Radwares Web site at www.radware.com. In
addition, a frontal review of AppWall can be scheduled with Radware sales
representatives, product marketing or product management staff.

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 3

2. PCI Compliance with Radware AppWall

The following sections outline how Radware AppWall addresses PCI 6.5 and 6.6
requirements.
2.1.

Addressing PCI 6.6 Requirements with AppWall

PCI 6.6 Recommended Capabilities

Radware Protection

Meet all applicable PCI DSS requirements

pertaining to system components in the
cardholder data environment.

Radware delivers its Application Delivery (ADC)

solutions, of which AppWall is an integral part.

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.

Fully covered by AppWall Web Application Firewall.

See Addressing PCI 6.5 Requirements with
AppWall and Addressing OWASP Top Ten with
AppWall sections for detailed information.

Inspect Web Application input and respond

(allow, block, and/or alert) based on active policy
or rules, and log actions taken.

All Web Application input is inspected and is either

allowed or blocked based on policy rules, while
configurable event logs are created. All HTTP
content is parsed, normalized and validated for
security policy match. For example, for each query
parameter there can be a rule (learned
automatically) defining its size, type and value.

Prevent data leakage, meaning having 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.

All Web Application output is inspected and

sensitive data is either masked in response, or the
entire response is blocked. For example, when a
Web Application response contains CC numbers,
those will be masked by default.

Enforce both positive and negative security

models. The positive model (white list) defines
acceptable, permitted behavior, 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.

Both positive and negative security models are

available using AppWall, providing protection from
both known and unknown attack types and
techniques. For example, protection from known
attacks is part of a negative security model while
resource access control is part of a positive
security model.

Inspect both Web page content, such as

Hypertext Markup Language (HTML), Dynamic
HTML (DHTML), and Cascading Style Sheets
(CSS), and the underlying protocols that deliver
content, such as Hypertext Transport Protocol
(HTTP) and Hypertext Transport Protocol over SSL
(HTTPS). (In addition to SSL, HTTPS includes
Hypertext Transport Protocol over TLS.)

All types of Web pages are inspected, including:

dynamic, static, CSS, etc.
Both HTTP and HTTPS (SSL v2, v3, TLS v1) are
supported either using AppDirector, or natively on
AppWall.

Inspect Web Services messages whenever Web

Services are exposed to the public Internet.

SOAP and XML (both document and RPC) are

supported and inspected. For example, content

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 4

PCI 6.6 Recommended Capabilities

Radware Protection

Typically this would include Simple Object Access

Protocol (SOAP) and eXtensible Markup
Language (XML), both document- and RPCoriented models, in addition to HTTP.

from client-posted XML files are extracted and

validated for content length type and value.
In addition, AppXML, Radwares XML and Web
Services Gateway, complements AppWall
functionality by providing Web Services security
protection capabilities.

Inspect any protocol (proprietary or standardized)

or data structure/format (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.
Note: Proprietary protocols present challenges to
current WAF products, and customized changes
may be required. If an applications messages do
not follow standard protocols and data
constructs, it may not be reasonable to ask that
an application firewall inspect that specific
message flow. In these cases, implementing the
code review/vulnerability assessment option of
Requirement 6.6 is probably the better choice.

Proprietary protocols are not supported in AppWall

out-of-the-box. However, depending on the nature
of the protocol, it may be possible to customize
AppWall to allow for a firewall solution providing a
robust inspection capability.

Defend against threats that target the WAF

product itself.

AppWall protects itself from any Web-based

attacks.

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.

The Radware ADC solution terminates all SSL/TLS

traffic prior to security inspection, enables Client
Certificate validation, and enables re-encryption of
traffic to the Web Server (configurable).

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 5

PCI 6.6 Additional Recommended Capabilities for

Certain Environments

Radware Protection

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.

Session information is encrypted by AppWall

before being sent to the client. For example,
cookies, hidden form fields and parameters can
be configured to be encrypted.

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.

Every release of AppWall includes new signatures

and updates to rules, to be applied by an easy
process.

Fail-open (a device that has failed allows traffic to AppWall is a reverse proxy which by definition
pass through uninspected) or fail closed (a
cannot be fail-open.
device that has failed blocks all traffic),
depending on active policy.
Note: Allowing a WAF to fail open must be
carefully evaluated as to the risk of exposing
unprotected Web Applications to the public
Internet. A bypass mode, in which absolutely no
modification is made to the traffic passing
through it, may be applicable in some
circumstances. (Even in fail open mode, some
WAFs add tracking headers, clean up HTML that
they consider to violate standards, or perform
other actions. This can negatively impact
troubleshooting efforts.)
In certain environments, the WAF should support SSL, SSL Client Certificates and proxying client
Secure Sockets Layer (SSL) client certificates and authentication are supported both using
proxying client authentication via certificates.
AppDirector and natively on AppWall.
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.

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 6

Additional Considerations

Radware Protection

Sites that rely on unusual headers, URLs, or

cookies may require special tuning. WAFs often
enforce maximum sizes for these components.
Additionally, the signatures they look for may
filter out specific strings perceived as exploits
that in fact may be perfectly valid for a specific
application.

All maximum sizes of cookies, parameters,

headers, and message bodies are configurable in
AppWall. In the event of false positives as a result
of valid requests containing exploit signatures, a
simple Refine button-click will refine the security
policy and prevent such events from recurring in
the future.

Content that does not conform to HTML/HTTP

RFCs or is other wise unusual may also be
blocked without tuning of the default filters. This
could include anything from overly large file
uploads to content submitted in foreign character
sets or languages.

There is a configuration option to avoid HTTP RFC

enforcement. AppWall delivers full support for a
large number of foreign character sets and
languages, installed in many American, European
and Asian countries.

DHTML, Asynchronous JavaScript and XML

(AJAX), and other dynamic technologies may
require special consideration, testing, and tuning.
These applications sometimes assume they have
access to a Web site in a way is perceived as
malicious by a WAF.

AppWall handles dynamic technology-based

traffic.

Applications that require information about the

underlying network session, such as client IP
address, may require modification if the WAF acts
as a reverse proxy. Generally these WAFs will
place client-side information into an HTTP
header, which existing applications may not
expect.

Since AppWall is a Reverse Proxy, original clientside IP addresses can be placed in an XForwarded-For HTTP Header according to the
practical de-facto convention.

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 7

2.2.

Addressing PCI 6.5 Requirements with AppWall

PCI DDS section 6.5 provides Web Application development guidelines that are referred to in
section 6.6 as minimal WAF requirements. All of these requirements are the same as
presented in the OWASP top 10 detailed in Addressing OWASP Top Ten with AppWall section,
where we explain how AppWall covers all of the OWASP Top 10 Requirements.
From PCI DSS, version 1.1, Section 6.5:
Develop all Web Applications based on secure coding guidelines such as the Open Web
Application Security Project guidelines. Review custom application code to identify coding
vulnerabilities. Cover prevention of common coding vulnerabilities in software development
processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and
session cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management
All the vulnerabilities and threats mentioned above are covered in Addressing OWASP Top Ten
with AppWall.

3. Addressing OWASP Top Ten with AppWall

The Open Web Application Security Project (OWASP) Top Ten provides a minimum standard
for Web Application security. The OWASP Top Ten represents a broad consensus about

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 8

what are the most critical Web Application security flaws. Project members include a
variety of security experts from around the world who have shared their expertise to
produce this list. OWASP urge all companies to adopt the standard within their organization
and start the process of ensuring that their Web Applications do not contain these flaws.
Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the
software development culture within your organization into one that produces secure code.
The following table summarizes the OWASP Top Ten vulnerabilities in Web Application
security, classified by OWASP:
OWASP
Vulnerability
Class

OWASP Summary Description

Radware Protection

A1 Unvalidated
Input

Information from Web requests is not

validated before being used by a Web
Application. Attackers can use these
flaws to attack backend components
through a Web Application.

AppWall validates all user inputs

provided by parameters, XML or Web
services, using different security
filters. For example, query parameters
are validated for size, type, and value
according to manually or learned
security rules

A2 Broken
Access Control

Restrictions on what authenticated

users are allowed to do are not properly
enforced. Attackers can exploit these
flaws to access other users' accounts,
view sensitive files, or use unauthorized
functions.

To prevent an attacker from being able

to access other users accounts,
AppWall protects the HTTP session,
using a strong cryptographic module,
while the access to sensitive files is
prevented using strong and
automatically configured access
control mechanisms. For example,
AppWall can be configured to prevent
any access to Web files except for
those that are configured accordingly.

A3 Broken
Authentication
and Session
Management

Account credentials and session tokens

are not properly protected. Attackers
that can compromise passwords, keys,
session cookies, or other tokens can
defeat authentication restrictions and
assume other users' identities.

AppWall prevents Brute Force attacks

on user authentication systems and
protects session hijacking and cookie
poisoning attacks by encrypting
session parameters and cookies,
before being sent to the client.

A4 Cross Site
Scripting

The Web Application can be used as a

mechanism to transport an attack to an
end-user's browser. A successful attack
can disclose the endusers session
token, attack the local machine, or
spoof content to fool the user.

AppWall prevents Cross Site Scripting

by identifying scripting patterns and
blocking the malicious request.

A5 Buffer
Overflow

Web Application components in some

languages that do not properly validate
input can be crashed, become
unavailable, and in some cases, used

As aforementioned, all possible types

of user input are validated for size,
type and content thus preventing any
possible buffer overflow attack.

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 9

to take control of a process. These

components can include CGI, libraries,
drivers, and Web Application Server
components.
A6 Injection
Flaws

Web Applications pass parameters

when they access external systems or
the local operating system. If an
attacker can embed malicious
commands in these parameters, the
external system may execute those
commands on behalf of the Web
Application.

AppWall eliminates injection flaws by

screening all user input for known
patterns and a large number of logical
rules to tell the difference between
legitimate user input and injection
flaws. For example, an SQL injection
contained in a parameter will be
inspected for all those rules to prevent
SQL injection.

A7 Improper
Error Handling

Error conditions that occur during

normal operation are not handled
properly. If an attacker can cause
errors to occur that the Web Application
does not handle, he can gain detailed
system information, deny service,
cause security mechanisms to fail, or
crash the server.

AppWall prevents sensitive

information leakage as well as error
messages to the client.

A8 Insecure
Storage

Web Applications frequently use

cryptographic functions to protect
information and credentials. These
functions and the code to integrate
them have proven difficult to code
properly, frequently resulting in weak
protection.

AppWall encrypts session information

on its way to the client and decrypts it
on its way to the Web server. Thus,
AppWall prevents any weak protection
implementation in the Web
Application.

A9 Application
Denial of Service
(DoS)

Attackers can consume Web

Application resources to a point where
other legitimate users can no longer
access or use the application. Attackers
can also lock users out of their
accounts or even cause the entire
application to fail.

AppWall delivers several protection

methods from different DoS attacks
such as opening multiple TCP
connections, parameter buffer
overflow, etc.

A10 Insecure
Configuration
Management

Having a strong server configuration

standard is critical to a secure Web
Application. These servers have many
configuration options that affect
security and are not secure out of the
box.

By applying Resource and Folder

Access Control in AppWall, any access
to folders and configuration files can
be prevented.

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 10

 2008 Radware, Ltd. All Rights Reserved. Radware and all other Radware product and service names are registered trademarks
of Radware in the U.S. and other countries. All other trademarks and names are the property of their respective owners. Printed
in the U.S.A.

Radware AppWall: PCI 6.6 Compliance

White Paper

Page 11