So the eternal question about the difference between PCI DSS 6.5 “web application” and the 6.6 “web-facing application”.  The intent of 6.5 is for internally developed, Internet and intranet facing web-applications.  PCI DSS 6.6 is meant for Internet-facing web-applications, and NOT for Intranet use.

But is it this simple?  Trey Ford does not think so and proposes that changes in the network edge make us reconsider scope and what “web applications” really mean.  Adobe AIR is moving web-applications to the desktop, cell phone, and intranet appliances.  Right now, we have the above definition for what is Internet facing vs. not, but one day in the future the landscape of web-applications may change.  Does not mean we may need web application firewalls (WAF) on the internal network?  Probably not, but as the attacks change so do the protection measures.

Popularity: 25% [?]

Today the PCI SSC added a new standard to the running list of standards and documents it manages (PCI DSS, SAP, SAQ).  We reported this was going to happen back in November of last year.  The Payment Application Data Security Standard (PA-DSS) is now formally a standard that the Council manages.  Check out the press release here.

PA-DSS is the Council-managed program formerly managed by Visa Inc. and known as the Payment Application Best Practices (PABP). The goal of PA-DSS is to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, other sensitive authentication data or PIN data, and ensure their payment applications support compliance with the PCI DSS. PA-DSS requirements apply to payment applications that are sold, distributed or licensed to third parties. PA-DSS requirements do not apply to in-house payment applications developed by merchants or service providers that are not sold to a third party, but these applications must still be secured in accordance with the PCI DSS.

In addition to the standard itself the Council has also released a frequently asked questions for the PA-DSS.

Will the PCI SSC accept applications that have been previously validated under the existing Visa PABP program?

PCI SSC will recognize PABP validated payment applications and list them with the appropriate PABP version that they were validated against. For payment applications validated against pre-PABP version 1.3, they must undergo a PA-DSS assessment within twelve (12) months after the initial publication of the PCI SSC list otherwise they will expire and will no longer be accepted for new deployments. For payment applications validated against PABP version 1.3, they must undergo a PA-DSS assessment within eighteen (18) months after the initial publication of the PCI SSC list. For payment applications validated against PABP version 1.4, they must undergo a PADSS assessment within twenty-four (24) months after the initial publication of the PCI SSC list. Please refer to the table in the Grandfathering PABP Applications section of the PA-DSS Program Guide for more details.

How will the migration to PA-DSS impact vendors previously validated under PABP? Read the FAQ!

Check out the full FAQ documentation for all the fine details.  I’m happy there is so much infomation being released surrounding every document released by the Council!

Check out all the documents online:

• PA-DSS Security Audit Procedures
• Summary of PABP to PA-DSS Changes
• PABP to PA-DSS Transition
• QSA Validation Requirements - PA-QSA
• Program Guide
• PCI PA-DSS FAQs

Popularity: 25% [?]

Jay from the USA asks:

If our acquirer provided POS systems, do we need to make sure that the acquirer’s equipment and websites are PCI DSS compliant?

I’ve always said that you should “Trust but Verify”!  It is very common for a merchant to receive or be recommended a certain POS system, application, or platform from their acquirer, processors, or franchise manager.  If you are a merchant who receives such a recommendation, be sure to do your homework.

First, you need to check the Visa website to make sure that POS system/software has undergone rigorous security testing and has been validated as secure under the Payment Application Best Practices (PABP).  You can see a list of qualified products here.

Next, you need to obtain the “Implementation Documentation” or “Implementation Guide” from that POS vendor.  Although your POS may have been validated as secure, there are still a number of things YOU NEED TO DO to operate it in a secure manner.  This documentation or guide is the list of thing you need to do.  Follow it carefully and understand how to protect yourself.

Finally, you are 95% of the way there, you need to continually educate yourself about the difference between compliance and validation, the definition of cardholder data and where to find it, who to contact in the event of a compromise, etc.  You may follow this blog or you may enroll in structured learning.  Either way, you need to keep yourself informed.

Popularity: 41% [?]

I really like the reminder that Mike Rothman has to say about compliance, “The sad truth is that compliance is still the engine that is running most security operations.” Let’s not forget that the people who complain about compliance are also those who’s jobs are based on necessity for it.  Business is an easy formula: make more money and reduce your costs.  Is security is perceived as an unnecessary cost, it too will be reduced.

So instead of bemoaning and fighting the various aspects of compliance, why not leverage them to benefit the business.  Mike continues:

As we focus on 2008, the first order of business for security professionals should be implementing a structured security program that is focused on protecting what’s most important to the business, setting goals and milestones to ensure accountability and communicating how and why certain security controls are implemented. The end goal is to distinctly show the value and importance of security to the operations of the business.

So what’s next?  Well, those long time readers of this blog will know that it’s in inclusion of the Visa USA PABP into the PCI suite of standards under the PA-DSS moniker.

“With the PA-DSS managed by the council, we will ensure that payment application providers and their products are subject to data security requirements consistent with the current PCI DSS.”  Bob Russo,
general manager, PCI Security Standards Council

Furthermore, Visa has taken a proactive approach and outlined a series of Payment Application Security Mandates. These mandates outline the phasing out of vulnerable applications and phasing in of validated application with a fine deadline in 2010.

Popularity: 24% [?]

So you might have read the recent Visa (USA) timeline for migrating to more secure point-of-sale (POS) technology. Or maybe you are looking at your aging systems and wanting to take the plunge and upgrade to a sexier, and more secure, system.

Here are a few things to consider before taking out the check book and laying new infrastructure.

1. Ask your acquiring bank if your prospective POS is a known vulnerable payment application. As the deadlines loom for payment application security some vendors may be looking to exploit a loophole in the system. You may notice that in 2008 companies cannot board new merchants using known vulnerable payment applications, so some of them may try to offload that technology before the end of 2007. The kicker being that in 2009 those companies may have to upgrade again to remove those known vulnerable systems. (More importantly, you may be installing a system known to make your environment non-PCI compliant.)
2. Confirm that your prospective POS vendor and version number is listed as a validated payment application. Visa publicizes a list of validated payment applications. If the integrated POS (IPOS) is not on that list — caveat emptor — regardless of what the vendor may tell you to the contrary. (This process is to be taken over by the PCI SSC in the coming years [PDF].)
3. Ask your payment application vendor or reseller for the Implementation Guide (or Implementation Documentation).  So you purchased and installed a validated payment application — you may be safe and you may not.  Each validated payment application comes with an instruction manual for configuring that app in a secure manner.  Without this Rosetta stone you may be living in a false sense of security.  It is a requirement that vendors and resellers provide this to you and educate you about it, but sometimes these things are overlooked.  Make sure you read and understand this document.
4. Encrypt data from the POS to the back-end systems.  Even though the payment application may be securing the data on the system itself, many are still transmitting the track data across the network to the back-end systems for authorization.  It is not a PCI requirement to encrypt this data, but recent compromises have shown that hackers are using technologies such as MPACK to sniff track data from the POS to the back-end systems.  Choosing a POS that has the ability to encrypt this data puts you one step ahead of the hacker.
5. Keep your POS network (and retail systems) segmented from the rest of the network (and from the Internet).  Network segmentation sounds like a monolithic task for some companies, but I’m only going to discuss two types here: segmenting one store from another, and within each store the cardholder data from all other systems.  It is well known that if you have stores directly connected to the Internet instead of a totally private network then you are a higher risk for compromise.  Also, if an attacker can compromise the wireless in-store network you want to make sure they cannot use that vulnerability to compromise cardholder data or any other retail store.

Knowing how the attacker thinks will help in defending against their most common attacks.  There is no way to have zero risk but we can limit it enough to have the hacker go elsewhere.

Know their weak points in the same way they know yours.

Popularity: 52% [?]

The PCI Security Standards Council (SSC) has updated their online FAQ to include questions and answers about the newly added PA-DSS.

When will the Payment Application Data Security Standard be available?
The Council has distributed a preliminary version of the PA-DSS for feedback from the PCI SSC Board of Advisors, participating organizations, QSAs and ASVs. A final version of the PA- DSS is expected to be published in the first quarter of 2008.

It also has questions on being a PA-QSA, so keep watching for updates.

See also other posts on the PA-DSS.

Popularity: 44% [?]

In early September the PCI SSC added the PIN Entry Device (PED) standard to its dossier of oversight items. Then at the end of September they announced the success of the first ever Community Meeting for Participating Organizations.

Now in early November they start the transition of the Payment Application Best Practices (PABP) from Visa and rename it the Payment Application Data Security Standard (PA-DSS). This follows the heals of the recently released Visa Payment Application Security Mandates.

It is important to focus on this area as it shows a strong push towards the security of smaller merchants (i.e. Level 2-4). It is widely known that many small merchant use similar point of sale (POS) technology and that the greatest risk to those merchants is from the compromise of those systems that store sensitive authentication information.

By turning the best practice document into a standard and then enforcing it with hard deadlines for compliance, the industry is delivering a 1-2 punch to the insecure systems and helping eliminate fraud in the smaller merchant arena.

Popularity: 58% [?]

As many people have noted, Visa released their Payment Application Security Mandates last week.

Visa will implement a series of mandates, beginning January 1, 2008, to eliminate the use of vulnerable payment applications from the Visa payment system. … These mandates are intended to prevent cardholder data compromises and thereby help mitigate the risk of associated financial losses such as liability from the Account Data Compromise Recovery (“ADCR”) program.

As with many things compliance related they will be phased in starting with the elimination of vulnerable payment payment applications for newly boarded merchants and then the overall requirement for the sole use of validated payment applications.

1. Newly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors (“VNPs”) and agents must not certify new payment applications to their platforms that are known vulnerable payment applications. Effective date: 1/1/08
2. VNPs (VisaNet Processors) and agents must only certify new payment applications to their platforms that are PABP-compliant. Effective date: 7/1/08
3. Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PABP-compliant applications. Effective date: 10/1/08
4. VNPs and agents must decertify all vulnerable payment applications. Effective date: 10/1/09
5. Acquirers must ensure their merchants, VNPs and agents use only PABP-compliant applications. Effective date: 7/1/10

There is a list of vulnerable payment applications available via Visa Online (sorry, merchants only.)

It is important to note that the deadline for Phase V is aligned with the Triple Data Encryption Standard (“TDES”) usage mandate for all Point-of-Sale (“POS”) PIN entry devices (“PEDs”) to be using TDES to protect PINs. Additionally, all attended POS PEDs must be evaluated by a Visa-recognized laboratory and approved by Visa prior to this same date.

Also remember that:

The PCI Security Standards Council (“PCI SSC”) will be adopting Visa’s PABP and plans to release the standard as the Payment Application Data Security Standard (“PA-DSS”) in the next year. References to PABP will be modified to reflect PA-DSS upon release.

Popularity: 36% [?]

As you may have noticed things have been slow here, due mainly to all the work happening in September. The end of Q3 2007 has been one of the busiest times for PCI DSS compliance.

• Visa consolidated many of their regions and are now known as Visa, Inc.
• The September 30 deadline for Level 1 compliance validation passed and everyone has been rushing to submit their report on compliance (ROC).
• There is lots of conversation regarding the Payment Application Best Practices (PABP)
• And if you haven’t been, be sure to read all of the alerts and bulletins.

Now we can relax until the end of December when Level 2 merchants must validate compliance.

Popularity: 29% [?]

I like to hear comments like those from Mike Rothman about PCI:

So what’s the bottom line? Basically, there is nothing required in the PCI DSS that is overly onerous. Any organization that has been taking security seriously for the past few years should be in pretty good shape. A well-run security program will put a corporation in a strong position to be compliant with most regulations, including PCI DSS.

Thus, I don’t think the PCI DSS requirements should be loosened. Maybe the timeframes could be extended a bit, but just because it’s hard, doesn’t mean it shouldn’t be done.

Here’s a good note about Kiosk security with relation to PCI.

If you live or work in California, don’t forget bill AB 779:

Earlier this month, California bill AB 779 was passed near-unanimously in both the State Senate and State Assembly, and it now sits on the Governator’s desk, awaiting the prodigious force of his personal stamp of approval.

At the center of the bill is a requirement that would force retailers like TJX Companies to reimburse banks and credit unions for any expenses those firms are forced to endure as a result of a data breach — namely for re-issuing credit and debit cards to those customers whose accounts have been exposed. Sounds fair enough, and other states are again expected to follow suit.

There is also an article about an application for mobile phones that enables proximity payments.  I’m happy to see companies all around the world adopting the payment application security practices.

Popularity: 28% [?]