What You Need to Know About PCI Compliance and Web Application Security Policy Changes
By Michael Sutton on Wednesday, April 16, 2008
If you are a merchant that processes credit cards you are probably well aware
of Payment Card Industry (PCI) compliance, but may not be sure how web application
security fits into the picture, or some of the changes that will be made in the
near future.
In June 2008, section 6.6 of the PCI compliance rules will go from “best
practice” to “mandatory requirement.” This means that some businesses may have
to reevaluate their web application security processes. If these security
practices were handled from the start, as the applications were built,
businesses would not be scrambling to add security to existing applications.
Unfortunately, this is often not the case.
What
PCI Compliance Means
As credit
card use has become more widespread both offline and online, and as consumer
concern about security has understandably grown, the credit card industries
have made an effort to ensure that sensitive information is protected.
In
September 2006, the major credit card companies (American Express, Discover
Financial Services, JCB, MasterCard Worldwide and Visa International) formed
the PCI Security Standards Council (SSC) and established a set of rules for
what they call PCI compliance. These rules have to be followed depending on the
size of a business and the number of credit card transactions handled, and if
done properly will help protect consumer data from theft.
The
Rules for PCI Compliance
The six
major categories within the standards established by the PCI SSC are as
follows:
- Build and maintain a secure network
- Protect cardholder data
- Maintain a vulnerability management
program
- Implement strong access control measures
- Regularly monitor and test networks
- Maintain an information security policy
Within these six categories are 12 requirements that address particular
issues and that are directly related to web application security:
- Install and maintain a firewall
configuration to protect cardholder data.
- Do not use vendor-supplied defaults for
system passwords and other security parameters.
- Protect stored cardholder data.
- Encrypt transmission of cardholder data
across open, public networks.
- Use and regularly update anti-virus
software.
- Develop and maintain secure systems and
applications.
- Restrict access to cardholder data by
business need-to-know.
- Assign a unique ID to each person with
computer access.
- Restrict physical access to cardholder
data.
- Track and monitor all access to network
resources and cardholder data.
- Regularly test security systems and
processes.
- Maintain a policy that addresses
information security.
Each requirement for PCI compliance is broken up into a variety of
subsections that go into detail about the process, and the full list can be viewed
at www.pcicomplianceguide.org. Section 6.6
- the most important subsection regarding web application security because it
is coming under scrutiny this year - states the following:
Ensure
that web-facing applications are protected against known attacks by applying
either of the following methods:
- Having all custom 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.
As a result of this upcoming change, companies should have a game plan
in place for web application security. Until now, companies may not have taken
PCI compliance very seriously. No major fines have been levied for
noncompliance so far and the entire process may have been seen as nonessential.
But with this new change to 6.6, IT teams around the world are evaluating the
strengths and weaknesses between web application firewalls, code reviews and
application assessment software.
What It
Means for Your Business
Many
businesses and government organizations have historically focused their
attention on network security rather than web application security, and it may
seem that the June 2008 deadline is coming out of nowhere and that businesses
will be scrambling to achieve PCI compliance. But businesses should have
ensured that all of its web applications were secure from the beginning. PCI
compliance shouldn't be viewed as a checklist, because then unreliable fixes
may be applied to problems. Instead, web application security should be
implemented within the web application itself. When web application security is
implemented properly, the PCI compliance requirements related to web
application security are automatically met.
As a
result, the development and quality assurance (QA) teams at businesses need to
be focused on web application security. Businesses may need to break their web
applications down from the start, rather than trying to install patches and
fixes for PCI compliance.
Section 11
of the guide could also cause problems in the near future. It states that
security scans must be done on a regular basis. If web application security
issues are not fixed internally, and patches have been installed as an
afterthought, these scans could become quite a nightmare because they will
identify hundreds of issues that will need to be fixed. It’s better to take the
time to build in web application security measures and avoid this problem
altogether.
Conclusion
After
section 6.6 of PCI compliance becomes mandatory in June 2008, businesses that
process credit cards will have to work harder to be PCI compliant, and evaluate
their web applications very carefully. By ensuring that web application
security is built from within, rather than by adding on fixes that will only
work in the short term, businesses will find that not only are they compliant
with one part of the PCI standards, but that they are compliant with all of
them, and that customer data is secure across the board.
Michael Sutton
HP Software
hp@mediumblue.com
|