PCI Council And Passwords: Do As We Say, Not As We Do
Written by Evan SchumanThe council’s own passwords wouldn’t pass PCI rules. The PCI Council has never been a stranger to irony. But its internal password procedures—the ones that protect the PCI Standard itself (literally the Word document version of the standard)—may be taking the encrypted irony cake. Those procedures actually violate at least four PCI requirements, plus a few standard security rules.
First, to be fair, what’s being protected is not especially sensitive. Specifically, the password is not intended to keep out prying eyes. Rather, its sole purpose seems to be to keep meddling fingers away. The Council apparently doesn’t want anyone out there to be able to edit the standard and then to produce the modified file as proof of a particular position. The password often frustrates people who have to work with the document, though, because it prevents them from copying a section and forwarding that text to someone.
But in an attempt to protect the integrity of the document—which tells retailers how to maintain payment card security, including, deliciously, rules for setting passwords—the Council decided to lock it down before posting it on the PCI Web site. PCI’s rules require passwords to be changed every 90 days, prohibit group/shared/generic passwords and require passwords to be at least seven characters long and contain both numeric and alphabetic characters.
Additional rules, typical for any security shop, include prohibiting passwords that are in the dictionary and certainly ones that are easily guessable. And yet, the password for the PCI DSS document seems to violate the four password rules contained in its words (that’s about as quintessentially ironic as anything could get), in addition to the dictionary and guessable rules. It’s—wait for it—pcidss.
When one QSA was asked about the password, he guessed it on his first try—once he was told that it was quite guessable. He then tried the same password on some PCI FAQs, and it worked. (Same password for multiple files? That’s got to be in somebody’s password rules somewhere.)
As mentioned earlier, these documents don’t include credit card numbers or other sensitive information. But if the decision is made to lock them down, there’s presumably a reason. If the concern is that QSAs or merchants can change the document, then the Council needs to choose a password that will indeed create the desired protection.
That said, another unwritten rule is that passwords need to be changed the moment a breach occurs or the password otherwise gets out. StorefrontBacktalk‘s PCI Columnist, Walt Conway, and I have a bet on how long it will take the PCI Council to change its password after this story is published. Want a piece of the action?
-Marc
February 24th, 2010 at 4:02 pm
If they don’t want the document changed, they should save it as a PDF and be done with it.
February 24th, 2010 at 4:13 pm
Not necessarily. PDFs today can be edited quite easily, unless they have password-protection activated, in which case you’re back to the same issue again. Besides, the council DOES offer these documents as PDFs already.
February 25th, 2010 at 8:37 am
Given they do not collect store or transmit card holder data, they are not subject to the specification.
February 25th, 2010 at 8:45 am
True, but that’s not the point. If they have chosen to password protect a file, it’s interesting that they didn’t adhere to their own recommendations. Compliance is not the issue. As we–and tons of others–have noted, PCI is not just for payment. Officially, of course, it is, but the guidance, guidelines and best practices contained in PCI is a good tool for anyone to use when needing to protect any kind of data. Lots of companies are using their suggestions to secure CRM data and many other kinds of information. The irony here is that the PCI Council didn’t opt to use its own advice.
February 25th, 2010 at 9:03 am
Irony?
From the association that was created to inflict tissue-paper security protocols on the rest of the world, and whose mandate is to punish organizations that don’t build a proper steel safe to guard their used tissues?
Their foundations were built on irony. Why are you so surprised?
February 25th, 2010 at 10:24 am
One of my pet peaves with passwords is the 90 day rule. That, more than anything else I would imagine, is the reason you find passwords written on the back of postit notes attached to monitors.
February 25th, 2010 at 10:30 am
At least it appears that they’ve removed the spot for credit card information from their fax forms.
February 25th, 2010 at 11:09 am
PCI applies to the storage, processing and transmission of cardholder data, and nowhere else. Provided there is no cardholder data in a given segment, that environment can be placed out of scope for PCI. This article seems to further assume that not only is the Council storing cardholder data, but they haven’t segmented their network to take the zone where this article is stored out of scope.
The idea of a standard implies uniform application. There is no expectation that we deploy PCI across zones that are out of scope. Ergo there should be no expectation the Council do otherwise. There is enough expense, confusion, difficulty, concern, criticism, and mud-slinging in this environment already. Neither increasing the scope, cost, and complexity of PCI to areas out of scope, nor expecting the Council to act differently than those its standards govern, advances the cause of Information Security in general or cardholder data security in particular.
February 25th, 2010 at 11:31 am
As an ex IT auditor (you never really become an ex auditor) I have several comments on this particular non issue. First of all I feel that the document should be one that the PCIDSS has in their possession with their own security. I really don’t see the purpose or the reason to password protect the document. If a level whatever credit card processor wants to make changes to the document and they compare the original with the one submitted this would in my view be fraud and subject to some very serious fines.
In another light I see this as one of the better standards as it does require companies and Government agencies to become better at security. To me it’s like the intro class to IT security for the dummies of management who have no clue how to spell security.
As far as the audits are concerned. I hope not to be disappointed. But we’re being audited by KPMG for PCI compliance. This is like Auditor appreciation week as we’ve decorated the office with all things for the auditor. The sign in sheet we put up at the computer room door with badges the Friday before the auditors come in. Management here thinks auditors are just stupid. And personally if these young wet behind the ears auditors buy off on all these fake decorations I have lost all faith in audit.
It appears they are asking some pretty interesting questions which indicate a lot of follow up to what I see as dead ends. Which I hope they address.
The problem to me is that in the past when auditors draft their findings they usually get fired. Then two years later we get a few more new kids come in with their check lists. I really hope these ‘kids’ are good at what they do, else management will celebrate how well they can pull the wool over the eyes of children.
February 25th, 2010 at 2:26 pm
Harry Maggiore, can i get this in writing ?
>Given they do not collect store or transmit card >holder data, they are not subject to the specification.
i have proven to my QSA that we do not collect any card holder data within our system except for the last four digits… and i am still required to implement all 12 PCI requirements throuhout the whole IT landscape and infrastructure.
Yes, we are a retailer, and yes, we do a lot of credit card business… but we do not store card holer information other than the ccPAN masked, with only the last 4 digits visible. But that doesn’t seem to be enough to be PCI compliant ?
the irony in the PCI council though, as mentioned in the article… very enjoyable. :-)
Carsten
February 25th, 2010 at 5:00 pm
@Carsten – you are forgetting the “Transmit” portion of scope which likely applies to you.
In general QSA’s have know how to unlock this document for a very long time(Insert Object –> Select file). I am not sure why they choose to lock it in the first place, but they have been doing this for years.
I do not think it is a fair statement to suggest that the council is following bad password practices for something as meaningless as protecting the integrity(vs confidentiality) of a document. There is a big difference in terms of value(and risk) in using weak passwords on a POS system and using a weak password to protect a document.
Now if someone were to hack into their portal and execute a successful SQLinjecton attack, that would be ironic.
February 25th, 2010 at 8:54 pm
Editor’s Note: The story does not suggest that PCI should apply to anything beyond payment. But it does acknowledge the reality–a reality that is not a bad thing, actually–that many businesses do use the best practices included in the standard as guidance for a wide range of security practices. The irony we noted was that the PCI Council opted to not be among them.
February 26th, 2010 at 11:54 am
The word version of this document only exists so that self-assessors preparing a ROC have a document into which they can enter their data. It’s a tool provided for convenience. It’s not the PCI equivalent of NIST’s meter bar, an item that it is essential it be kept inviolate in a tightly controlled environment to maintain the integrity of the standard.
Let’s ask the Security Question: What was the RISK here? If a user chooses to hack the password and alter the document, they’re not hurting anyone but themselves. No forensic investigator s going to go by their altered document nor is it likely to stand up in front of a jury. Mom always said, “If you’re fooling yourself, you’re fooling the biggest fool of all”. IMHO the Council made a risk-based decision and chose to secure the document at a level they deemed appropriate. PCI DSS was never in play, either as a standard or a best practice.
I am advocating focus on REAL issues that matter to this community: lowering the cost and complexity of PCI by treating it as the business problem it is, identifying cost-effective steps for making PCI more accessible to small businesses (who represent the majority of compromises), identifying the impact of compliance-enabling technologies, or the explaining the advantages of getting to validated hardware and software to lower risk.
March 2nd, 2010 at 7:57 pm
Irrelevant…no credit card, no PCI, no DSS.