advertisement
advertisement

New PCI Rules Will Force Retailers To Set The Risk Level

Written by Walter Conway
July 10th, 2012

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

PCI version 2.0 changed July 1. There actually are no new requirements, per se. But as of this date, the stated “best practices” for identifying and ranking risk vulnerabilities in Requirement 6.2 became mandatory. Merchants and service providers need to realize that this change reverberates through at least two other PCI requirements. Merchants and service providers who ignore this change may find themselves up a PCI tree later this year or when they begin their next compliance validation, especially if they don’t update their internal vulnerability scanning procedures.

As I wrote when PCI version 2.0 emerged in 2010, there were “evolving requirements” in the new version as well as clarifications of some existing ones. For the evolving requirements, the PCI Council gave merchants one-and-one-half years to plan their implementation before the changes became mandatory. We are now through this “best practices” period and, effective July 1, the new requirements are in place.

The principal change is to Requirement 6.2, which states that merchants and service providers must “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.” This requirement applies to everybody. What changed from the previous PCI version is that it is the merchant or service provider who develops the risk ranking. The guidance indicates that the ranking should be on industry best practices, and this can include outside sources such as application vendor guidance, security Web sites or Common Vulnerability Scoring System (CVSS) scores.

This change generated a lot of discussion and anxious questioning when the Council unveiled it at the 2010 PCI Community Meeting. The Council’s intent was to give merchants flexibility in identifying and ranking risks based on their own industry and operating environment. The tone of the questions from the floor, however, challenged whether merchants had the security knowledge, expertise or even the time to assign these risk rankings.

Assigning the risk rankings is not to be an academic exercise. Those rankings feed back into at least three other PCI requirements.

One affected requirement is a subsection of 6.5. That requirement tells service providers and merchants who write payment applications that they must develop that code securely to prevent common vulnerabilities such as SQL injection, cross-site scripting, buffer overflow and insecure error handling. Under sub-requirement 6.5.6, merchants and service providers now must also reflect the risk rankings they developed under 6.2 in their application development process. Specifically, they must prevent those vulnerabilities they classified as “high” in 6.2.

A similar change is in Requirement 2.2, which tells service providers and merchants to update their configuration and system hardening standards to reflect those “high” vulnerabilities from 6.2.

However, it is the new internal vulnerability scanning requirement that will most likely affect the greatest number of merchants and service providers in the coming months.

Requirement 11.2.1 requires service providers and merchants to perform internal vulnerability scans at least quarterly or when there is a significant change in the network. What changed on July 1 is that now these internal scans have to include the high vulnerabilities identified in 6.2. As before, rescanning is required until passing results are obtained.

Keep in mind that PCI compliance requires passing quarterly internal scans for each of the previous four quarters. Therefore, the risk for merchants who neglect to identify and rank their vulnerabilities is that they will fail to scan for them and, as such, their internal vulnerability scans will be incomplete. As I’ve noted before, developing a backward-looking compensating control is possible, but it can test the creativity of the best QSA.

My advice for all merchants and service providers is to make sure you comply with the “new” Requirement 6.2. Then reflect those vulnerabilities in both your code development process and your internal vulnerability scans. Another clarification in 11.2.1 is that the scans must be performed by a “qualified” person who has “organizational independence” from the network being tested. In practice, this would include either an internal or an outside tester who has the expertise to run the scanner and interpret the results but is not involved in the management or administration of the target systems.

I suggest consulting with your security team and your QSA if you have any questions on these new requirements or their impact on your assessment. The time to get ready for your assessment is now, not in three or six months when you could already be looking at having incomplete or noncompliant internal scans.

What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me.


advertisement

One Comment | Read New PCI Rules Will Force Retailers To Set The Risk Level

  1. Cathy Says:

    I’ve created risk matrices for almost everything in Infrastructure. I started with the application which relied on what environment it was in, what operating system was installed, whether the application contained PII, etc. It is not as hard as it sounds if you just extrapulate each component which could contribute to the risk and make it logical.

Leave a Reply

Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 17,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.