Attacks on web-facing applications are

Feature
Understanding How to Protect
Web-facing Applications
Under the Covers of Requirement 6.6 of PCI
Sushila Nair, CISA, CISM,
CISSP, is a product manager
at BT Counterpane and is
responsible for compliance
products. Nair brings 20 years
of experience in computing
infrastructure, business
security and a diverse
background. She has worked
with the insurance industry
in Europe and the US on
methods of quantifying risk
for e-insurance based on
ISO/IEC 27001.
Doug Drew, CISSP, PCI
QSA, is a senior security
consultant with BT INS. He
has been working with PCI
DSS since 2006 and has
conducted numerous PCI
engagements for BT INS,
covering a diverse range of
industries. Drew specializes in
risk management, regulatory
compliance and security
The Payment Card Industry (PCI) Data Security
Standard (DSS) is an excellent standard around
which to build a data protection framework.
The standard is built on analysis of data security
breaches and the requirements are built around
preventing the top sources of data loss. The
standard does not guarantee data security,
but it ensures that sensible controls are put in
place to prevent the majority of the causes of
security breaches.
Since February 2005, according to the data
available on Privacy Clearing House, 140 million
records have been breached and approximately 80
million of these were due to web hacking attacks.
Any organization that is concerned about data
breaches must be aware of the risks associated with
web-facing applications. It is clear that the forensics
on data breaches done by the card companies have
pointed to web-facing applications as a high area of
risk and, therefore, the standard has incorporated
controls to reduce this risk.
This article focuses on section 6.6 of DSS,
which aims to protect organizations from data
loss/breaches through web-facing applications.
In June 2008, the PCI Security Council began
enforcing section 6.6 of the DSS, which states:
program development.
Peter Verderber, CISA,
CISSP, PCI QSA, is a
principal consultant with BT
INS and has more than 10
years of experience in the
field of information security.
Verderber specializes in risk
management and compliance,
nsure that all web-facing applications are
E
protected against known attacks by either of
the following methods:
• Having all customer application code
reviewed for common vulnerabilities by an
organization that specializes in application
security
• Installing an application-layer firewall in
front of web-facing applications
helping organizations
effectively address
information security from a
business perspective.
The intent of the section is to protect against
application vulnerabilities. The guidance
on interpreting the standard clarifies this
requirement further by stating:
ttacks on web-facing applications are
A
common and often successful, and are allowed
by poor coding practices. This requirement
for application code reviews or applicationlayer firewalls is intended to greatly reduce
the number of compromises on web-facing
applications that result in breaches of
cardholder data.
Application Vulnerabilities
Requirement 6.6 is based on the assumption
that most internally developed code is
considered untrustworthy, i.e., applications
that are developed in-house are not subject to
the same level of application testing that thirdparty vendors conduct. (It is interesting to note
that in spite of the large budgets reserved for
application testing by software companies, many
new software vulnerabilities are announced
almost daily. This highlights the importance of
application testing for organizations that have
neither the inherent skill set required nor the
bandwidth to conduct the same level of testing.)
There have been several theories about the
relationship between the number of source
lines of code (SLOC) and coding errors. The
relationship between the two is dependent on
the language, quality assurance process, testing
and other quality control factors. However, it
is obvious that the larger and more complex
the application, the greater the likelihood for
programming errors.
Classic vulnerabilities range from an online
bookstore that did not test for customers who
would enter negative numbers for purchases
and, thus, credited customer bank accounts
upon purchase, all the way to web pages that
have revealed personally identifiable information
(PII) of customers. Most developers will admit to
developing for functionality, with security simply
ISACA JOURNAL VOLUME 4, 2009
1
being an afterthought. A good development practice does
help reduce the number of bugs, but it simply cannot eradicate
human error. The results of coding errors can carry significant
risk, especially with those applications that are business-critical
and store confidential data.
In its Q3 2007 Application Security Trend Report, Cenzic,
an applications security testing specialist organization, details
1,471 unique, published vulnerabilities it observed, with
cross-site scripting (XSS) and Structured Query Language
(SQL) injection standing as the most prevalent issues resulting
from poor coding.
The most recent report estimates that 71 percent of all the
vulnerabilities reported worldwide during the fourth quarter
of 2007 were related to web applications—affecting everything
from servers to browsers and representing a 3 percent increase
over the previous quarter. Even worse, Cenzic contends
that roughly 70 percent of all reported web applications
vulnerabilities could be classified as “trivially exploitable.”
Code Reviews
One possible solution for reducing the risk associated
with vulnerabilities in web applications is code reviews.
Code reviews can be done manually or through the use of
automated tools. Doing a code review for an application that
has been working uninterrupted for years (as is often the case)
usually proves futile. Often the coders are not there anymore,
the coding language is obsolete and the business impact of
touching the application may be higher than the fines involved
in not being compliant. Ethical hacking can be used as a
method of testing the application’s security and may be more
effective than a review of source code. Ethical hacking will
reveal application vulnerabilities and should be performed by
a company that has a proven track record within this arena.
Web Application Firewalls
Another possible solution for protecting web applications is
to use a web application firewall (WAF). WAFs are designed
to make fine-grained decisions about traffic based on rule
sets. These security devices have extra intelligence compared
to network perimeter firewalls and the ability to learn. Early
WAFs had issues surrounding performance, because deep
packet inspection by its nature results in slower throughput.
There are three major categories of vendors offering WAFs:
optimization platform vendors, such as F5 Networks Inc.;
network perimeter vendors, such as Check Point Software
2
ISACA JOURNAL VOLUME 4, 2009
Technologies; and application- and database-aware hybrids
that protect the web application and the database, such as
Imperva Inc. All of these firewalls have the capability of
understanding application-layer traffic and can protect against
application attacks, such as SQL injection. Most WAFs have
standard signatures to protect against well-known attacks,
such as worms and SQL injection attacks. These devices
also have the capability to learn how users access web pages
and can alert or block unusual access, such as entry of an
SQL command into an input field, thus preventing an SQL
injection attack in a poorly coded application that did not do
input validation correctly. The learning component, called
profiling by some vendors, also provides protection against
zero-day attacks, which may not have a signature associated
with the attack pattern. Figure 1 shows how to set access
parameters around input from the WAF without making any
changes to the application itself.
Since WAFs do content inspection, they can also be used
for inspecting and alerting to types of data being accessed, i.e.,
credit card numbers or other confidential data. Some WAFs
provide support for Secure Sockets Layer (SSL) by allowing
the key to be loaded on to the WAF, and, thus, encrypted
traffic as well as standard HTTP can be inspected. Criticisms
of WAFs include the difficulty of deploying and tuning these
devices. However, this market is gradually improving.
The classic WAF is simply performing fine-grained
inspections of packets and, if required, blocking traffic that
is deemed to be in some way dangerous. This obviously can
be achieved by an intrusion prevention system (IPS). WAFs,
however, like all security products, are taking additional
security enhancements, such as database application
monitoring (DAM), code review and policy enforcement,
to a data content level. It is likely that WAFs will converge
with Extensible Markup Language (XML) security gateways.
There are enormous benefits in protecting data with devices
that understand content of the data, including the ability to
enforce data protection framework policies, such as those for
US Social Security numbers and credit card numbers, and to
be able to protect from common application-layer attacks.
Issues With WAFs
When customers deploy the application-level protection in
their network firewall, they often wonder whether missing the
additional protections available by WAFs puts them in danger.
The answer is not that clear, especially since the configuration
Figure 1—Setting Access Parameters With WAF
of most WAFs is so complex that they often give the user
a false sense of security. Moreover, WAFs do nothing to
reduce the risks in which vulnerabilities (bugs) in applications
themselves result (essentially, arbitrary downstream events,
such as unrestricted database queries). At the end of the
day, the question that customers need to ask themselves is
whether their application can be manipulated in such a way
that the payment card information residing in the database
layer can be compromised. It can be argued that positioning
an application-aware network firewall in front of the web
application and a good monitoring and attack prevention
system on the database layer is the most practical solution
with the most predictable security outcome.
Database Application Monitoring
DAM and protection helps customers comply with other
sections of PCI DSS (including sections 2, 3, 7, 8, 10, 11 and
12) and the same is true for network firewalls (mandated
by section 1). A highly effective and arguably much better
alternative for a WAF is the combination of DAM, an IPS and
an effective firewall.
A good database monitoring and prevention system in
the database layer (provided by vendors such as Sentrigo,
Secerno, Tizor and Guardium) can help stop attacks that
have somehow made it through the firewall and reached the
database. For example, by merely protecting the dictionary
tables of databases, a prevention system can thwart most
attacks that begin by trying to figure out the structure of the
databases (to find the way to the payment card information).
Vendors who are able to inject the original application user
and URL add another layer of protection by limiting (for
example) the ability of some users to access or make changes
to cardholder tables. Some systems offer fine-grained access
policies with deterministically zero false-positives that enable
only acceptable queries to critical database tables.
Issues With DAM
DAM can be challenging to deploy as it requires tuning. The
complexity of the solution varies from vendor to vendor, but
to get real value from the products, the software needs to
be configured and alerts need to be defined to ensure that
sensitive data loss is monitored appropriately. One of the
other problems with DAM is the inability of products to track
the identity of the end user who is accessing the database.
Most web applications are configured to log in to the
database using a single account; therefore, any product that
is monitoring the database will not see the end user accessing
the data, but rather the account configured on the web server.
ISACA JOURNAL VOLUME 4, 2009
3
Most DAM solutions offer work-arounds to this problem with
varying levels of success. One of the very innovative solutions
is combining web application monitoring with DAM from a
single vendor, such as the solution offered by Imperva. This
provides a solution that combines the strength of WAFs and
database monitoring and provides user tracking.
Choosing a Solution
WAFs and DAM are not an excuse for careless development
practices. They are, however, excellent solutions for reducing
the risk of web application vulnerabilities. Both solutions are
complex, but as attacks become more complex and difficult
to discover, a solution that provides the capability to monitor
is extremely important. In the case of the large credit card
breaches at Hannaford and TJX, the data loss was discovered
by the bank and not the merchant. And, both organizations
implemented monitoring solutions after the breaches were
discovered. It makes sense to implement a solution that
monitors for data loss before the organization hits the
headlines in a similar manner.
DAM does not stop the application server from being
compromised and being used as a launch pad into the
database. However, threats from the outside world are only
one avenue of attack. There is a clear argument that the
control should be as close as possible to the asset, so that all
avenues are protected. The move away from signature-based
attack detection to anomalous access or behavioral access to
the asset results in the widest range of detection of attacks,
though the tuning may be more complex initially.
Code review is a very important component of application
security quality assurance. The code review should be
conducted by a third party that specializes in this area; desk
checking or having a trained colleague wading through lines
of code is unlikely to reveal application flaws. In particular,
code review should concentrate on the threat to critical data
in databases, which can be achieved accurately and completely
only by measuring actual database access, e.g., using database
behavioral analysis tools, such as Secerno’s.
Ethical hacking is arguably the most effective method of
code review. Ethical hacking is a highly skilled task, and it is
best to select an ethical hacking company that has been rated
by recognized agencies, such as the US National Security
4
ISACA JOURNAL VOLUME 4, 2009
Agency (NSA), rather than one that simply tells good war
stories. It is possible to use an automated tool for code review,
such as Coverity which was developed in the Computer
Systems Laboratory at Stanford University in Palo Alto,
California, USA, from 1998 through 2002.
It makes sense, no matter what solution is chosen, that
the organization should test that the solution works either by
using a respected firm or by using ethical hacking.
Conclusion
Application-level attacks are one of the top five causes of
account data compromise. Good development practices may
reduce bugs, but, as it is human to err, good procedures will
never eradicate them. The PCI DSS requirement to install
an application firewall is simply one way of protecting data.
Organizations should not follow the mandate blindly, but
rather determine what they are trying to achieve and ensure
that they have a solution that fits into their monitoring
security architecture and reduces risk without a corresponding
increase in complexity.
In conclusion, it can be argued that implementing a
centralized monitoring framework with either an IPS and
a DAM solution, or a WAF and a DAM, will result in the
highest level of protection for the organization’s critical asset.
References
Imperva, www.imperva.com
Sentrigo, www.sentrigo.com
Secerno, www.secerno.com
Burton Group, “Web Application Firewall Market
Maturing,” http://searchsecurity.techtarget.com/news/
article/0,289142,sid14_gci1218724,00.html
Cenzic, Q3 2007 Application Security Trend Report, www.
cenzic.com/news_events/Cenzic_AppSecTrends_Q3-07.php
Cenzic, 2008 Application Security Trend Report, www.cenzic.
com/pdfs/Cenzic_AppSecTrends_Q1_2008.pdf
Payment Card Industry, Navigating PCI DSS:
Understanding the Intent of the Requirements, v1.1, https://
pcisecuritystandards.org/pdfs/navigating_pci_dss_v1-1.pdf