Thanks to the EUCI!
Thanks to everyone at EUCI and their great hospitality in Vail. I'm looking forward to working with some of you soon!
Thanks to everyone at EUCI and their great hospitality in Vail. I'm looking forward to working with some of you soon!
The PCI landscape is pretty scary out there. If you are a merchant or service provider that is looking for assistance, there is a long line of companies that are ready to help. What should you expect from your QSA? What should your assessment look like to get the best results?
VeriSign reviewed our findings from our customers and wrote a white paper entitled, "Not All QSAs Are Created Equal: What You Should Know Before You Buy" that talk about what you should expect. This paper is a FREE download! Go check it out!
About a month ago an audio guy showed up to my house and pinned a tiny microphone to my shirt for a podcast on PCI. It is a joint podcast with John Pescatore of Gartner. The theme is on managing PCI Compliance.
I was asked this question while sitting on a panel at RSA, and I think the answer depends on your perspective. I'll answer this from a security industry perspective.
If nothing else, you have to credit PCI with forcing the issue. Security among retail enterprises was generally limited to loss prevention and physical security until recently. Information security usually existed as a small and buried team within the Information Technology group, and did not have board level attention. If someone at the board was savvy enough to realize that security reporting to IT is an example of the fox guarding the hen house, then maybe they moved security into Internal Audit.
Now we are seeing a massive amount of development in security and compliance programs. Where companies had a staff of two or three to handle this, they now have large, global teams to deal with this. PCI forced the issue, then higher ups started asking questions about HIPAA, GLBA, and others.
Security teams now report into the office of the CFO, or Legal, and in many cases have their own seat on the board. Budgets are opening up, and money is being spent. Without fail, more issues are found while every stone is turned over to see what bugs lie beneath.
Poetic, don't you think?
The next test is to see if the strategy component has been handled such that you can sustain the support to the organization, and avoid bureaucratic bloat. PCI can't get you there, only good old security process will.
Your QSA may not be telling you the whole story.
No, I'm not talking about sloppy assessment work. What I'm referring to is a clause that is supposed to be in your contract with your QSA. The DSS Validation Requirements for Qualified Security Assessors requires that QSAs put a notification in their contracts with their customers telling them that the ROC and supporting materials can be disclosed (Section A.6.3 in the doc linked above). Why does that language need to be in the contract? Because the QSA agrees to send the ROC to certain parties per the operating agreement!
In a recent competitive bid situation, we were informed that two (of four) bidders DID NOT have such language in their contracts! This means that the QSA has a choice. They can either breach the agreement they have with the Council, thus quickly getting them delisted as a QSA. Or, they will breach YOUR contract and send the info along without your consent!
I am surprised that QSAs are doing this, and wondering what their intentions are. If nothing else, if you get a contract without that clause in there, what does that say for the quality of the assessment you will receive?
If you had any action on the Vegas odds for the release of the next DSS and what it might be called, time to cash in. I was speculating that it would occur around the time of the conference this year, and it would have been called 1.2 (vs 2.0).
Ahh, you win some, and you lose some.
The official release is here, and hints that there may be some new requirements coming down the pipe. They typically give 18-24 months to implement, so no need to panic now. But watch out for more controls around wireless!
Well? Will you?
We're waiting!??
Hopefully your bank is not taking THAT approach to checking on your status, but I know many merchants are feeling the heat. Jaikumar Vijayan from Computer World writes that when this deadline passes, most people will not be in compliance. If you read the letter of the law, yes, I would agree. But based on the guidance released by the council, if you are compliant with the rest of the standard, there is a pretty good chance you are compliant with 6.6.
In this clarification, The Council declared the intent of the code review component to include "Manual web application security vulnerability assessment" and "Proper use of automated web application security vulnerability assessment (scanning) tools." So essentially if you are getting something like VeriSign's Premium Vulnerability Management Service, you meet this requirement. You could also count your penetration test as long as the application has not changed since that penetration test was performed, and it covers the entire application with manual interaction. VeriSign's Penetration Testing services DO cover this.
There will be some merchants that do not meet the requirement; but those merchants have likely been doing just the bare minimum, or "Managing Checkmarks," as opposed to building a sound security infrastructure and fitting compliance inside it. Merchants doing that are probably not fully compliant on any given day anyway.
Do you wonder if the consultants that your QSAC sends on-site are actually QSAs? Well now you can check! For some reason, all of VeriSign's QSAs don't appear in this list, but we're diligently working to correct that. I can only imagine the large QSACs are probably flooding Cathy with email right now.
One of the arguments for becoming PCI compliant is to keep this an industry regulated certification, versus having to deal with a federal mandate like Sarbanes-Oxley. People often ask me if I think PCI will become a federal mandate. I don't think it is possible.
Most federal mandates are designed to protect their citizens (I said MOST... ok?). The electronic payment system already has mandates to protect the citizens. For example, did you know that the Fair Credit Billing Act limits your liability to $50 for unauthorized charges? Personal experience says $0 liability if the physical card is still in your possession.
PCI is designed to minimize losses to issuers and the brands caused by a credit card breach and instill confidence in the payment system. As an important side effect, it promotes information security inside retailers and reduces the losses that would be associated with a breach of their systems (potential brand damage, fines, and consulting fees).
Since the citizens are already protected, and breaches do not directly affect the money system (they affect companies), I don't believe the federal government will get involved. We've seen a state governments pass legislation, but it is still untested in the courts and I have doubts on its ability to be enforced. Keep in mind, credit card fraud is not the same as identity theft, and I believe we will see much more legislation on that in the future.
The PCI Security Standards Council released a statement yesterday defending the PCI-DSS against claims that the standard is not strict enough and will not protect against common attacks. This is the first real communication we've gotten from the council since the announcement of the Hannaford breach earlier this year.
This statement is the first to be released to try and counter the negative press from Hannaford telling the world that they were compliant with PCI. This was the first breach of a Level 1 merchant that had validated compliance through a QSA. After reading the statement from the council, vague as it is, merchants should feel better about their PCI programs.
The PCI DSS, if properly implemented on a merchant or service providers' network, provides the security controls necessary to prevent hackers from penetrating a payment environment and installing malicious software that would jeopardize the protection of card data as it is being processed.
So does that mean that PCI DSS was not properly implemented at Hannaford? If it was not properly implemented, how would they have passed a QSA's PCI assessment? Maybe the new Q/A program at the council will address something like this, but then again, maybe it is all up to interpretation?
I'm going to aggregate several PCI related things here in one post as it has been a busy week in PCI Land! I have other things I want to write about, so stay tuned for more stuff later today and throughout the week.
First off, the Council has released the Payment Application Data Security Standard (PA-DSS). This replaces Visa's Payment Application Best Practices program, and your Point Of Sale application should comply by July 2010, or your customers may not be able to accept Visa cards! Nothing we did not already know, but it is now finally released.
Next, the Council also released clarifications on Requirements 6.6 and 11.3 (apparently a very hotly debated topic in a recent QSA Requalification class). There are two very important issues to pull out of the clarification.
On Requirement 11.3 (annual penetration test), the clarification makes mention that the penetration test should also include an on-site (or internal) penetration attempt. This will drive the cost of these assessments up a bit, but I think there is some room for innovation. Just depends how risk-averse a company really is.
The real doozy is on Requirement 6.6 (periodic code review or web application firewall on all web-facing apps). There really appears to be overlap here now. In lieu of a code review or web app firewall, the Council has elaborated on how the intent of a code review can be carried out. They say that a "Manual web application security vulnerability assessment and/or proper use of automated web application security vulnerability assessment (scanning) tools" can be used in lieu of an actual code review.
In a normal application penetration test that VeriSign performs, we already would perform the above. Does that mean if you get a Penetration Test by VeriSign that you automatically comply with both 11.3 and 6.6? If we take the guidance of the Council, it does.
I was disappointed by the 6.6 clarification as it does not seem to have legs any more. VeriSign typically recommends that a code review be performed as part of your PCI strategy. We believe that you should fix the problem at the source (pun intended) instead of trying to put another filter in-line. Passive web application firewalls have their place in any sound security strategy, but the fact remains that the most effective way to remove the threat of these vulnerabilities is to fix the problem in the code.
As an example, during a recent code review we performed, we found several vulnerabilities that could be exploited that would not be caught through an automated tool, and yet could be exploited remotely. When you are working with the code, you don't need to manage the mask of the interface.
In other news, Visa released a bulletin on packet sniffing cardholder data, no doubt in response to a recent breach. VeriSign has often recommended using encryption over the wire to help reduce insider threats. Visa echoes that strategy in the recommended mitigation section.
OK, enough PCI for today!
Phillip Hallam-Baker commented recently on my post about the NRF, but specifically added to the chip and pin point. Thanks Phillip!
While others at VeriSign are headed to ETA, I took the opportunity to speak about PCI to the OpenTravel Advisory Forum in Atlanta today. A shout out to an excellent group of individuals that are in one of the more difficult industries with respect to PCI (the other being Fuel Dispensing). Thanks for the hospitality!
It appears that the PCI-SSC has finally released the new Payment Application Data Security Standard! You can read all about it here.
Clement James writes about a security expert that slams PCI, stating that the breach in the news "was almost certainly the work of hackers exploiting a single code flaw on internal systems." The expert goes on to say that "PCI takes a relaxed attitude towards internal machines."
While I agree that there is room for improvement on internal controls for PCI, remember, it's not designed to protect your entire enterprise. It is a basline, and you should layer security on top.
The challenge is this. Not until the end of last year did we see a compliance validation rate exceeding 60% among Level 1 merchants. If you make the standard too hard, you will have little or no adoption. You have to wait until you have enough momentum to add more security into it, but you will always have stragglers. The adoption rate would be easily less than 25% if there were more standards on internal encryption or device security.
Uh oh, look out world, here comes some new fangled technology!
Well, not that new.
But VERY new for the PCI Industry! The PCI-SSC has put RSS on their website! They now have a feed for News & Events which can be picked up at https://www.pcisecuritystandards.org/pcissc_news.xml.
The card associations that make up the PCI-SSC should take note. Currently, the preferred method of communication for all five members is reviewing their security websites. Unfortunately, it is pretty hard to see what changes unless some kind of alert is posted (and one association actually changed the URL that is listed in the QSA training we receive without a forward). VeriSign suggested RSS a while back as a good way to keep people informed to changes in the program. Hopefully the power of RSS will be addicting, and all the associations will start pushing updates that way.
Go subscribe today!
The PCI Security Standards Council looks as if they have released that FAQ they have been working on! I can tell you that this is a huge relief for everyone involved (merchants, service providers, QSAs, ASVs, etc.) as the volume of questions that the council was dealing with prevented them from turning around answers quickly.
Course, quickly is a relative term.
But consider their position. Here at VeriSign, we might submit 1 question every couple of months, but other QSAs may submit more. For every question that VeriSign (or any QSA) submits, they must get buy in on the answer from all 5 members before it can be turned around. You can see how this can easily take days or weeks to get answers turned around if you are getting any significant volume per day (say 10 questions per day).
So now that the common ones are up there, this should allow the more challenging interpretation requests to be processed quickly.
The PCI Security Standards Council has released the long awaited version 1.1 of the Self Assessment Questionnaire (or should I say questionnaires). The key thing here is that the validation requirements are different depending on the type of merchant you are. There are now 4 versions of the questionnaire as opposed to 1, and they do map to the current PCI 1.1 standards.
I think I assume that the intent is to keep the SAQ mirrored to the current version of the standards from now on, so we should see them updated this year if the standards are updated as planned. In addition, during the webinar call we asked if PA-DSS is still on track, and the response was "Yes," it should still be released this quarter. We're looking forward to that!
In Mike Dahn's PCI Answers blog, a post was made over the break about the Secure hashing of PANs
As this blogger has said on many occasions before, hashing is a double edged sword.
Theoretically, you could create a hash that is as secure as a CipherText from an encryption algorithm. If you used a 10 kilobit salt (effectively the Key) plus the PAN, you would have something quite secure and would not run into issues with collisions. The problem is that you cannot change your keys without retaining the original PAN. If you did change your key, new hashes of the same PAN would not match old hashes.
Perhaps the biggest issue, people treat hashes differently then they do CipherText. Hashes are seen as "non-real values that cannot be reversed." Unfortunately, you can subvert the complex math by building rainbow tables. Something we don't see is symmetric encrypted values thrown around an organization in the same manner. Why? Just attitudes on treating certain data in certain ways I think.
If you could solve the key change issue, plus keep hashed computations secure like you would CipherText, then maybe we can make an apples to apples comparison.
Visa just released slides from a webinar on Automatic Fuel Dispensers (AFDs) as it relates to skimming. Looking at the pictures they included, this is something we all could easily be victims of as there do not appear to be any external signs that you are becoming a victim of foul play (thanks Shane!).
AFDs are notorious for having these kinds of issues simply because there is not someone watching over them like a cashier does at a traditional Point of Sale (POS). We've seen examples of this occurring in ATMs as well. Not only is this a call to duty for AFD manufacturers to become compliant with PED and PA-DSS standards, but it is a call for merchants using these devices to enhance training and field checks to prevent this type of fraud.
Just got back from London (and I feel fantastic!), and they are really taking an interest in PCI. I found it very interesting that many of the Big 4 are still heavily involved in providing advice about PCI even though they are not Qualified Security Assessment Companies. The funny thing is that the UK seems to be where the US was about three years ago. Still in the discovery phase, and not a ton of C-level attention yet. Until Visa, Inc. puts something like the Compliance Acceleration Program in place over there, it will likely have a very slow adoption rate.
Hopefully Visa will give people at least 24 months notice, and the banks will over-communicate with their merchants so there is not a huge panic 6 months before the deadline.
Yep, more PCI posts.
Visa has just released their new Payment Application Security Mandates which give a new timeline for merchants to use PABP (or now PA-DSS) validates payment applications. If you are using a third party application and it is not validated by July 1, 2010, you will likely be subject to fines by your acquirer.
There are other items leading up to that, but this is the big one for most merchants.
We've all heard speculation, and even speeches where we were told this was coming, but it is now finally one step closer to reality. Today, the PCI Security Standards Council announced the Payment Application Data Security Standard, and its intention to release the new standard by Q1 of 2008. Unfortunately, to my knowledge the PA-DSS is not quite out of draft form yet, and is still sitting with the Members. Once it is clear of that review process, I hope that QSAs will be given an advance copy like we were of the proposed questionnaire. While we are prohibited in sharing the documents with our customers, we can speak to their makeup and how it might affect our them.
Stay tune for more information as it is released!
PCI-SSC has now announced Italian translations!
A Visa informational release Friday revealed that 65% of Level 1 merchants have now validated their PCI compliance. This is really no big surprise based on the acceleration program (CAP) that was put into place in December of last year. The message to the remaining 35% is pretty clear.
You are now in the minority.
While I am sure those merchants affected by PCI are well aware of their compliance programs, this may be that final driver to get top level buy in so that projects are appropriately funded and tracked. Most companies we work with have plans, but no support.
The card associations are sternly scolding non-compliant merchants this year, and the attention around PCI related issues has never been greater. Why is it so hard to comply? Surely merchants have some level of security around their customer data, otherwise there would be a compromise every week. Is it technology? Is it cost? Or is it just a lack of motivation from the top down to wrap up these compliance projects?
This year, we released a paper that reviewed 60 Reports On Compliance from 50 of our customers over a 15 month period. What surprised us was that what we perceived as one of the easiest requirements to meet--PCI Req 11.2, perform quarterly scans internally & externally--was the TOP failure! Why would something that is such a relatively easy process cause the most failure among our customers?
This issue has a relatively simple fix in our minds, though we also validated common industry buzz on items that are not. Logging and encryption continue to cripple companies pushing towards PCI compliance. Both of these issues require well thought out strategies that must encompass the entire enterprise to fully implement. Point solutions rarely if ever work in the long term, and their nature tends to cause short term gains to turn into long term costs.
Inside this paper, we explore many of these issues, and provide free tips on how to make smart decisions on becoming compliant with the PCI Data Security Standards without breaking the bank. Any company that is affected by PCI can take this paper to their organization for practical ideas on how to reduce the impact PCI has on their business.
In a website posting yesterday, Visa clarified on their Merchants page the requirements around quarterly network scans. From their site....
The Quarterly Network Security Scan is an automated tool that checks systems for vulnerabilities. It conducts a non-intrusive scan to remotely review networks and Web applications based in the externally-facing Internet Protocol (IP) address provided by the merchant. Acquirers are responsible for ensuring that the quarterly network security scans required of their levels 1, 2, and 3 merchants are performed by an Approved Scanning Vendor. The Quarterly Network Security Scan is applicable to merchants with externally-facing IP addresses as specified by their acquirer. Quarterly Network Security Scans are not required of merchants that do not have externally-facing IP addresses.
We've had some questions around quarterly scans recently, so thanks for the clarification!
Two weeks ago, we released our recent study on why companies are failing PCI. We based our report findings on 60 recent PCI assessments involving 50 different large companies. Since then, there have been multiple media outlets that have picked up and commented on the report. One in particular I'd like to review is an article by TechTarget (which interestingly enough, now has a new title).
When Keith Gosselin of the Biddeford Savings Bank in Maine was told that our report showed that nearly half of the companies are failing requirement 11.2 (quarterly scanning), he stated, "It surprises me how high that number is." I think this was a big shocker for us as well, but after letting the shock wear off, we created a couple of hypotheses around why this is failing.
1) Companies fail this because they are doing quarterly scanning, but are not scanning until they receive a clean scan (as required by PCI Requirement 11.2). Having an automated process run is pretty easy to do, but you also must remediate and rescan. Many of our customers did not close the loop.
2) Companies are not properly scanning internal systems. When we started this process many years ago, it was typically out of the IT or Security groups. Now we are working for the office of the CFO in most cases. Back then, most companies had at least 1 guy who could get a halfway consistent Nessus engine running. Today it seems priorities have changed, but someone forgot to set up an outsourced partner to do this. VeriSign currently partners with Qualys to perform this service (both internal and external scanning).
The other thing he mentioned was that he was shocked companies did not understand their data flows. Until recently, PCI has had a much more reactive and tactical effect on our customers. Now that some companies have seen the light and understand this type of compliance requires a programmatical approach, they are beginning to get to the root of the problem--the data. They know they have to find it, and then secure it. Surprisingly enough, it is a rarity that a payment system in a company is so simple that someone knows it from start to finish. I can think of a couple of examples out of the hundreds we have done. Knowing where your data lives is something I've discussed before, and will continue to be a struggle for companies as they grow.
My favorite comments in this article are from Roger Nebel, Director of Strategic Security for a consulting firm in DC. He states that the report doesn't always account for some critical differences and inter-relationships between a threat, a vulnerability, and an asset, all of which result in some level of risk.
Yep, you hit the nail on the head!
I do want to make a slight correction, however. The perceived problem is not with the report, but with the standard. In fact, there was a gentleman at the recent PCI Community Meeting with specific feedback for the council on creating a quantifiable method to calculate risk. While I seriously doubt that the council will want to create such policy around the standards, it is a valid point for those folks who are focused on doing the absolute minimum. The absolute minimum is sometimes a reality, but for those folks that complain that PCI is a moving target, I suggest they might want to strive for something north of the minimum so they are not continually chasing compliance like a cat chases a mouse.
Finally, Nebel took issue with our finding that clients who passed requirement 6 of PCI DSS still have applications at risk. My thoughts on this is that he was either mis-quoted, or he is not familiar with the PCI DSS. Specifically, if you look at the current version of PCI, requirement 6.5 lists the former OWASP Top 10. This year, OWASP released an updated version of the Top 10 which is still just a subset of the total number of application vulnerabilities that you might be able to find on any given day.
Granted, I think Nebel's point is that if you have a super-sexy Software Development Life-Cycle (SDLC), you should not have application vulnerabilities in the first place. PCI does not require, nor does it address fully, something like that. It just requires that security is baked into the SDLC, and it does not account for human error. After all, we are all people running this process. You can detail it all day, but that does not prevent someone from inserting some cryptic looking code that opens up a vulnerability.
PCI is trying to build a baseline, and baselines are good, but do not eliminate risk. Even if you take a conservative view on the standards, you still have risk in your applications if you fully meet requirement 6. Maybe that's another story for another time.
(Note, some sections of this post were taken from the TechTarget article to provide a common ground for comments. The full article for your reference is available at http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1273153,00.html.)
In an effort to continue to boost compliance, Visa USA is now publishing a report that details their merchant compliance by level. According to my contacts inside Visa USA, this list will be updated on a monthly basis. We are all expecting the numbers of compliant Level 1 & 2 merchants to increase as fine deadlines approach.
The PCI-SSC announced today (ok, the date says Tuesday, but it was not posted until this morning) that they are adding PIN Entry Device (PED) security requirements into their domain of responsibility.
Late last night (well for me in Central time), Visa posted a new brief on their CISP website regarding eliminating the storage of prohibited cardholder data. Essentially, this is just another data brief explaining how to look for and remove prohibited data. Prohibited data as defined by the PCI Data Security Standards, Requirement 3.2, includes such things as CVV/CVC Data (as found in the magnetic stripe of the card), CVV2/CVC2/CAV2/CID (3 or 4 digit code in the signature panel or front of the card), and the PIN or PIN Block. According to the brief, there has been a number of compromises recently where prohibited data was stored.
For more strategies on eliminating cardholder data, please read my paper entitled "More Strategies for Eliminiating Cardholder Data".
I had a customer ask me if they had to make the Administrator account/password comply with Requirement 8 of the PCI Standards. Requirement 8 deals with assigning a unique ID to each person with computer access to those systems dealing with cardholder data. Specifically, no generic or shared accounts should be used--especially those that are administrators!
The answer is YES, they must comply with the requirements. What does that mean from an operational standpoint?
We see customers attack this from various angles. For those corporate systems, they are typically just disabling the Administrator account, and putting special alerting in place to see if it is ever used (as in something bad is happening, go deploy the calvary).
In the case that you have a non-directory setup, things become much more painful. You are essentially looking at deploying a password escrow type service where no one person knows the password, only the system does. Passwords would then be checked in and out, and either stored in a secured area (think like a vault) with appropriate logging. Essentially, if someone uses that account, you want to be able to prove which individual used it since the logs will just say "Administrator" or "root."
More than half of the customers we deal with have directory services deployed to all systems, albeit in many cases multiple directory services. In one case, a customer standardized completely on Active Directory and RACF. All Unix variants pointed back to LDAP via Active Directory.
For our VERY FIRST installment of "What Do Other Companies Do" (WDOCD), Randy Smith has asked the following:
"What specifications do other companies require for Secure Tape Destruction (especially for older tapes that could have pre-encryption account number data). To my understanding PCI does not provide a specification.
What standard seems to be "secure enough" for older tapes potentially with unencrypted data?
Do you feel that standard is OK to relax when all the account number data is encrypted?"
Excellent question Randy! Virtually every company we work with has some sort of destruction policy for media, and it varies from using a bulk eraser, to pulling out the DeWalt and drilling a hole right through it (yes, one company we have done work for does exactly this after a bulk erase), to enlisting a third party media destruction firm, to transferring the media back to the manufacturer for analysis and destruction. A quick search on YouTube will show you many more creative methods to destroy these devices (though not recommended by this humble security consultant).
Specific to PCI, the only destruction standards mentioned are ISO standards that have nothing to do with destruction at all. Slight oversight that we hope will be corrected soon.
What is actually required is some method to destroy the data or media such that the data cannot be recovered. Small tape strips are minor risk, but incineration or shredding seems to be the best method to ensure the data is not recoverable.
For tapes where the account number is encrypted, I do believe a relaxed method would be appropriate. In fact, if you filled a FedEx truck with tapes of encrypted data, and then left it in the open for people to take those tapes, you would not be required under state laws (today) to notify the affected individuals! The card associations might take a different view of this of course.
The answer: For unencrypted tapes, be sure you do a very thorough degaussing before taking them to your vendor for physical destruction. This will ensure that any leftover fragments will not have any data on them to recover. For encrypted tapes, shredding with 3 to 6" tape strips left over should be acceptable.
Thanks for the question Randy! For your time, keep your eyes open for a little gift from us!
Well they are finally done! The PCI Security Standards Council has released the Spanish and Portuguese versions of the PCI Standards and Security Auditing Procedures.
Visit https://www.pcisecuritystandards.org/tech/supporting_documents.htm for more info!
Greetings folks. My new article entitles "More Strategies for Eliminating Cardholder Data" has now been published on the VeriSign website. This is an expansion of my previous article which primarily relied on Hashing. Based on clarifications from the card associations, hashing is not a silver bullet (do you know of any that are?) and hashed data is still considered cardholder data. The real risk is that rainbow tables can be created if someone knows how the hash is created. Since the keyspace is so small, the rainbow table creation is rapid.
This article expands that and takes a more holistic approach to data elimination and talks about many other strategies. It does not address the culture shift question that someone pointed out to me at an ISSA Meeting in Dallas yesterday, but that is for another time.
eWeek is reporting that Visa has announced it is relaxing the fine and fee deadline of September 30th.
Essentially, what this means for non-compliant merchants is that the proposed interchange rate hikes are lessened to simply say that non-compliant merchants will not be eligible for the "best available" tiered interchange rates. However, non-compliant retailers are still facing costs potentially in the millions by not being able to qualify for lower rates during the ever important holiday shopping season.