Bear with me as I tell you a short story.
“A long time ago, in a galaxy far, far away,” (thank you George Lucas) I worked with a very seasoned IBM systems programmer. He had the acronym ’R T F M’ neatly framed hanging behind his desk. I quickly found out what it meant the first time I had a problem with the mainframe that I could not solve. As I walked into his office carrying the huge case of paper that was my program dump, he pointed to the picture behind his desk.
“Yeah, so what?” I replied rather indignantly.
He said, “R T F M!”
“Yeah. And what the [expletive] is R T F M?” I replied a bit confused and frustrated.
He snapped back, “Did you Read The [Expletive] Manuals?”
RTFM was one of his few pet peeves. If you had read the manuals, he would help you as long as it took to solve your issue. If you had not read the manuals, you were quickly guided back out of his office and not so politely told to read the [expletive] manuals. If you then went and read the manuals and still had problems, then you could come back and ask for his help. Heaven help you if you still did not read the manuals and came back. I only saw it happen once and it was not pretty.
The reason I was brought back to this memory recently is because I am getting tired of people only reading the PCI DSS. It is painfully obvious from their questions that this is all that they have read. The PCI SSC’s Web site contains all of the documentation you need to interpret the PCI standards, yet it seems the only document that people download and read is the PCI DSS. All the rest of the documentation just seems to get ignored. If people were just reading the rest of the documentation that is available we would all be better off.
As a result, I thought I would take some time to walk people through the documentation that exists outside of the PCI DSS and explain why they should read it. In my opinion, the following documents are mandatory reading for anyone involved in PCI compliance efforts.
- PCI DSS Quick Reference Guide – At 30+ pages long, it is not as “quick” as one might like, but it is probably the best Primer you can get. If you are new to credit card processing, new to the PCI standards or an Executive just trying to figure this PCI thing out, this will get you up to speed in a hurry. This is the piece that you put in your Executives’ and Board of Directors’ hands to get them up to speed and should be mandatory reading before discussing PCI compliance.
- Glossary – This document should have been titled, “READ ME FIRST” instead of the Glossary as it is more than just a traditional glossary of terms. The Glossary explains key industry concepts as well as the terminology. In some cases, the Glossary explains key security concepts that are referenced in the PCI DSS. The bottom line is that this document should be read before reading the PCI DSS and then used as a key reference as you read the PCI DSS. Even for those of us “veterans” of the banking and technology worlds need to read this document just as a refresher. I would guess 45% of questions regarding the PCI DSS are answered just by the Glossary.
- Navigating the PCI DSS – This document explains the other 45% of the questions regarding the PCI DSS (I know, that only adds to 90%. The other 10% are valid questions). The key thing you will get out of this document is the intent of each of the requirements and some of the tests. This document should be read in conjunction with the PCI DSS as it will answer most of those, “Why in the world would I want to do that?” and “What were they thinking?” sorts of questions.
- Information Supplements – These are white papers published by the PCI SSC that explain technologies or concepts that can enhance PCI compliance and/or improve your security. As of January 2011 there have been seven of these published on topics such as wireless, penetration testing, code reviews and other key topics. This is where you can get all of that detailed PCI compliance guidance that QSAs have running around in their heads. The PCI SSC promises us even more of these in the coming years, so you need to check this section of the Documents Library regularly to make sure you have them all.
These documents are optional reading for any involved in PCI compliance efforts. However, the Prioritized Approach is a great tool to get you quickly moving on PCI compliance.
- Prioritized Approach for PCI DSS v1.2 – Okay, this is out of date and I am sure a new one will be produced. However, for those of you that want to focus on getting PCI compliant, this is for you. It will take you through the PCI DSS is a way that hits the requirements that are most important to least important so that you focus on big ticket, big bang requirements first and then work your way through the rest of the PCI DSS. For the most part, it still works with v2.0.
- PCI DSS Summary of Changes Version 1.2.1 to 2.0 – For those of you familiar with the PCI DSS and you want to know where the changes are between v1.2.1 and v2.0, this is the document for you.
The PCI SSC’s Web site has a wealth of information on its Documents Library page. Not only is the PCI DSS covered, but they also have all of the Self-Assessment Questionnaires and related documents, Payment Application Data Security Standard (PA-DSS), PCI Pin Transaction Security (PTS) as well as information on Approved Scanning Vendor (ASV) standards and other resources.
In addition to the Documents Library, there is also the ‘FAQs’ system. This is an interactive system that allows you to research questions that have been posed to the PCI SSC. So, before you ask your QSA that question, go to the ‘FAQs’ and look for it there. I would have posted a link, but it is a dynamic Web page and you must go to the page by clicking on the word ‘FAQs’ at the top of the Web page.
RTFM people! And for those of you that are curious; yes, I had read all of the relevant manuals.
PCI Guru 
I consider myself a security expert. When someone asks me a security question, I don’t snap back at them and say to go read up on it themselves before coming to me. They’re asking me a question because they pay me for my level of knowledge.
Just like if I see a doctor for an expert opinion on why my knee is sore. I don’t get a response about going to medical journals online and looking crap up first. I’m going to, asking him, and paying him to be someone who can give me expert advice.
My only problem with the RTFM analogy is that of subjectivity and interpretation. I consider good QSAs and assessors to treat their work like an art form, not *just* an objective by the numbers bullet list. Sure, they fill in check marks, but in a world of infinite configurations for IT/information and nearly infinite opinions on what is necessary to meet goals, then paying and subsequently asking questions, even dumb ones, of the experts should not be something that imposes any sort of passive or active punishment.
Being able to read, understand, and put PCI DSS into action is not easy, requires an expert, and requires significant internal experts from the business. Even a PCI DSS manual isn’t enough. Otherwise I wouldn’t constantly hear and even say, “It depends on your QSA.”
Agreed. Yes, I had a rant.
What I wanted to point out is that there is more to the documentation than just the PCI DSS, what other documentation is available, and how that documentation should be used.
And yes, I know that everything in the PCI DSS is not clear as rain. However, reading all of the documentation would go a long way to closing the gap between intelligent questions and questions that exist just because people have not taken the necessary time to read everything available. I just seem to cover the same ground over and over again on the basics. Not only about credit cards, but security as well. And I am not complaining about small and mid-sized merchants, I expect them to be pretty much clueless. However, I am talking about merchants that are large and should at least know the principles of security.
I also do not mind coming in and educating people. However, more and more people are just reading nothing and then want a detailed Cliff Notes version and the PCI DSS just doesn’t work that way. And they think you can do all of this in an hour. No security compliance program works that way.
It is becoming more and more apparent that people just are not doing their homework. And that is the thing that really irritates me. I am expected to always do my homework, to always have an answer, but everyone else seems to get a pass. Even QSAs that are supposed to know everything I know just are not taking the time to do the homework.
You can only serve as the Shell AnswerMan for so long before it wears you out. I just want people to do more research on their end so that things work better. I apologize if that is too much to ask.
I do hear ya on the point. Not sure what mood I was in when I responded, but I was a bit short myself. 🙂
Somewhere somehow there needs to be an expert around this whole process. I would hope such a person can be found in-house, since it is taxing to the QSAs to be that person for unenlightened companies (or even other peer QSAs!).
I was having a bad week myself and just wanted to vent. Too many people in too big a rush and not taking the time to do any research.
Nicely written post. As a systems architect, systems programmer, and systems manager, I cannot but agree that a vast percentage of the questions (and their inevitable followups) would be faster resolved if everyone would read the applicable documentation. One point that went unsaid, but implied, is that if one has “read the manual” one is in a better position to present an actual non-conforming behavior to the appropriate person when a seemingly unresolvable problem does occur. It was always far easier to troubleshoot an applications problem when the programmer came to me with the logs, dumps, and other information ready to be analyzed, rather than a long list of “Did I need that?”.
When confronted with poorly trained compliance personnel, familiarity with the documentation precludes the ever popular “puzzle the caller” response (citing a “document” that explains it all, and then implying customer ignorance). If one has familiarity, one is far better positioned to continue the “conversation”.
I would agree to an extent – I have heard many people ask questions that have not only been answered multiple times, but are also clearly answered in the documentation. However, expecting everyone to come away with the same understanding of what they’ve read is a bit far fetched. I can’t tell you how many times I’ve been told “It depends on your QSA” – aren’t they all going from the same documentation? Yet they clearly interpret it differently, and they’re the ones trained to understand it – expecting a merchant to understand it just as much, if not clearer (if only 10% are valid questions), is impossible. They haven’t had the training, may not retain it all, may not clearly understand it, may not have the time to read it all in the first place, and (in many cases) are hiring someone to help take care of it for them for the sheer fact that they don’t understand it. Would it be helpful if every merchant took the time to understand it better and be able to work with the QSA – sure. That’d help both sides as the whole audit process would go quicker and it’d help with 24/7 compliance instead of just check-box compliance. But the sad truth of the matter is many merchants don’t have the resources to do that.
I am not expecting the documentation from the PCI SSC to answer every question. As I pointed out, I estimate it will only answer about 90% of the questions asked. However, if everyone would read everything that I view as mandatory, a lot of the frustration we all have, QSAs and assessees alike would go away.
My point is that I think many questions arise simply from merchants not understanding what they’ve read or understanding it differently than a QSA would.
Yes – some don’t take the time to bother trying to understand and therefore questions that shouldn’t need to be asked come up… BUT I would argue that far less than 90% of the questions would go away as a result of simply reading the documentation. Again, they haven’t had the training… and even with training – QSAs come away with different understandings of the requirements. How can a merchant be expected to understand it and have less questions when they can get 3 different answers from 3 different QSAs?
Here’s a definition that is missing: Transaction
The validation method is done by the number of annual transactions, but that term is undefined.
If someone reserves a hotel room using a card but pays in cash, does it count as a transaction?
If someone buys something on a card and later returns it for credit, is it one transaction or two or none?
Is a “balance check” at an ATM a transaction?
If someone rents a car and the rental agency charges them and puts a hold on for an additional amount and then reverses the hold after the card is returned undamaged, is it one transaction, two or three?
These are actual questions our people have asked and I don’t know how to answer them other than “everything is a transaction”.
The short answer is you need to talk to your service provider that processes your transactions to get an accurate assessment of an organization’s annual transaction count. The reason is that every service provider counts things a bit differently in that some do a better job than others at breaking transactions out by type when they count them. Since your service provider is the one that the card brands will contact to confirm your transaction count, that will be the number you need to know not any statistics you pull from any other sources.
That said, here are the definitions as they have been explained to me by various service providers.
If someone reserves a hotel room but pays cash is a transaction in a sense. The hotelier does run a transaction of sorts through the system to ensure that the credit card being used to hold the reservation is good and that it will support the charges anticipated. However, no actual charges are actually placed against the card unless the hotelier tells the customer that it will charge some percentage of the room cost up front and the rest on checkout. However, from a service provider perspective, the check of the card counts as a transaction.
In your return example, that would be two transactions.
Balance checks at an ATM typically go through a different channel and may or may not count as a transaction.
Your rental car example should be counted as three transactions.
Now, just because they are transactions does not mean that they all count towards your merchant level status. As I stated earlier, some service providers break things out better than others. Usually, only transactions that involve an actual debit or credit to an account processed by the service provider are counted as part of the merchant level.
RTFM is no good unless you can UTFM. More often than not, auditees run across unfamiliar technology and minds will blank over when it comes to alien terms such as key management.
Asking a level 4 merchant to RTFM just doesn’t work – they’ll never understand it unless they have a CISSP and 5 years multi-domain experience under their belts.
I’d agree in that everything you need to know is definitely on the website, but conversely this is aimed at security professionals and your average merchant just doesn’t get it.
I was at Visa recently and their main criticism was that the SAQs were incomprehensible for 99% of merchants out there, which was ironic as Visa were the main drivers in authoring the standards in the first place. At least now they’ve absolved all responsibility and can now blame the PCI SSC…! 🙂
If someone does not read the manual, how can they understand it? Too many people read only the PCI DSS or their SAQ and nothing else. So my point is read ALL of the available documentation, not just one piece. If people did that a lot of what we run into in the way of issues would resolve themselves. However, that is not to say that this is an easy subject to understand and there will still be questions. But dealing with informed questions is a whole lot easier than what we have now which is just argumentative complaints in a lot of cases.
In response to your level 4 merchant comment. If level 4 merchants read only the Primer and nothing else, they would be hundreds of miles further down the road than they are now. That document alone describes in very clear, non-security professional terms the whole PCI security story, what needs to be done and why it needs to be done.