I had to prepare a presentation for a client a while back giving them some tips on how to prepare and get through a PCI assessment as easy as possible. I thought it might be good to share those thoughts.
Trust But Verify
This famous quote from US President Ronald Reagan is the mantra of a PCI assessment.
The PCI DSS is based on the “trust” that organizations are complying with the PCI DSS. However self-assessment processes and QSAs are used to “verify” that the organization is, in fact, complying with the PCI DSS. As a result, the organization being assessed not only has to produce documentation to that effect, but the QSA must also observe that the PCI DSS requirements are being followed.
The net is that, just because you say something is fact, your QSA must substantiate your statements so that they, too, will treat them as fact. If you remember nothing else but this simple truth, you will understand why a QSA must do what they do.
Scope
If PCI assessments go wrong for any reason, this is probably the primary reason. It fascinates me that people often profess ignorance of the PCI DSS, yet somehow become experts on the subject when it comes to scoping.
Remember point number one, trust but verify. Under that premise, the PCI SSC makes a QSA’s primary responsibility to confirm the scope of the PCI assessment as they verify the facts. As a result, in order to confirm that scope, the QSA must look at everything and then, through investigation and evaluation, determine that the areas you deem out of scope are, in fact, truly out of scope.
Let your QSA ask their questions and conduct their observations without arguing with them about scope. They are only doing this because they are required to confirm the facts and your fighting with them about scope is only going to making them wonder what you are trying to hide. The bottom line is that arguing with your QSA about scope only makes your assessment all the more painful and time consuming.
If you truly want to avoid arguing over scoping, get a copy of the Open Source PCI Scoping Toolkit. Go through your environment and determine the categories of all of your systems and networks. This is a good annual exercise because you need to prove your scope every year.
Applicability
According to the PCI SSC, there are five PCI DSS requirements that can never, ever be marked as ‘Not Applicable’: 1.2.3, 3.2.1, 3.2.2, 3.2.3 and 11.1. I have discussed these all before but they deserve another quick discussion here.
Clients will argue ad nauseam that wireless is not implemented or is out of scope and therefore refuse to discuss wireless. For requirement 1.2.3, a QSA is required to document the procedures they followed to rule wireless in or out of scope. That of course means the QSA must investigate any wireless networks and evaluate if the controls are rigorous enough to keep wireless out of scope. For requirement 11.1, the QSA must investigate and evaluate if the organization’s controls surrounding the detection of rogue wireless are appropriate regardless of whether or not the organization has implemented wireless networking.
3.2.1, 3.2.2 and 3.2.3 are all related to the securing of cardholder data when it is stored. Even if an organization is not storing cardholder data on their systems, a QSA must document the procedures they used to confirm that cardholder data is not stored on the organization’s systems. This usually involves a review of flat files and database schemas and the running of utilities and queries against those systems and databases looking for cardholder data.
The bottom line is do not argue about something being ‘Not Applicable’ and then hinder the QSA’s investigation to prove it is ‘Not Applicable’. Do not get me wrong, you need to keep your QSA on point, but remember that QSAs are required to evaluate the situation and then document the process used to determine that a particular requirement is ‘Not Applicable’. All you do by complicating that investigation is add more time to your assessment and, potentially, cause a requirement to be marked as ‘Not In Place’ instead of ‘Not Applicable’.
Yes, I Did Kind Of Ask That Earlier
Like security, the PCI DSS also works from a ‘defense in depth’ approach. A lot of the questions QSAs ask are very similar just asked from a different perspective. The people that develop assessment and audit programs will tell you that this is the most effective way to uncover the level of compliance with a given program. The reason is that organizations who have not integrated a compliance program into their day-to-day operations will typically provide inconsistent or confusing answers to the similar questions. Not that this is a perfect technique mind you, but it does work the majority of the time.
Please be patient with your QSA. They did not write these procedures, but they are required to execute them.
Answer The Question
Most people suck when being questioned, particularly in a legal proceeding, including yours truly. Lawyers always instruct anyone that will be called to testify in a legal proceeding to take their time, focus on the question being asked and only answer the question being asked. Never, ever, ever provide any information outside of the question, i.e., do not elaborate. The trouble is that lawyers know that silence is a vacuum and it is human nature to fill that vacuum with extraneous information. Hence why they typically have long pauses between questions.
QSAs and auditors tend to operate under the same principle as a lawyer. People get into trouble when they start talking about things that are outside of the question, out of scope or not relevant to the assessment. Such responses will at first confuse the QSA for a moment as they try to reconcile your remarks. But then, the QSA may question whether they truly understand the environment and, possibly, the scope of the assessment. It is then that they may start quizzing you and your staff as they go back and reconfirm their understanding of the environment. All of this takes time, time away from the assessment process as you cover old ground while the QSA re-verifies the facts.
The lesson to be learned here is that there is nothing wrong with saying, “I do not know.” Or “I will have to look into that question and get back to you.” The worst thing you can do is try and “tap dance” around the question or never really answer the question. If you do not have the answer, then find out who does have the answer and point the QSA to that person.
Prepare
And finally, the best thing you can do to avoid all of these issues is to walk through the PCI assessment process and requirements with those of your staff that will be interviewed/observed and make sure they understand the questions to be asked and how they should be answered.
If you really want to know what the QSA will ask, why they will ask and the evidence they will require, get a copy of the PCI DSS ROC Reporting Instructions from the PCI SSC Document Library. The Reporting Instructions document is the “Bible” for QSAs as it documents how they will be assessed in a PCI SSC Quality Assurance review. Reviewing and understanding this document will go a long way to minimizing the “What do you need that for?” questions that all QSAs encounter.
For each requirement’s tests, the Reporting Instructions will tell you:
- What observations, if any, need to be performed and documented.
- What documents, if any, need to be collected and reviewed and what information needs to be identified in those documents.
- What people, if any, need to be interviewed and about what topic(s).
- What processes, actions taken or states of equipment, if any, need to be observed and documented.
- Whether or not sampling can be used.
Using the Reporting Instructions, you can also gather a lot of the observations ahead of time. Your QSA will still have to conduct some observations such as that default passwords are not used, that timeouts occur, that change management operates and the like. But by gathering screen shots and documenting what you used as testing conditions will go a long way to making your assessment go much more smoothly and quickly.
Hopefully this discussion will help you get through your next PCI assessment without all of the associated drama that can come from such an exercise.
PCI Guru 
Thanks for this article, being in the same boat as kentzhou, i’m preparing the company for SAQ D tier 1, i found myself back at the scoping stage trying to eliminate as many components from the scope as possible.
I have a few questions i was hoping you can shed some light on:
1) Regarding key management in encryption; would GnuPG suffice ? if not what would you recommend ?
2) I always found the definition of what is in scope very vague and unclear:
“A cardholder data environment is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication.”
Does this mean that any piece of hardware that stores, processes or transmits Clear full PAN data only ? so if the PAN was partly hashed and stored on a mobile phone, would that make the mobile phone in scope ?
3) If we fail the assessment, is there a cool down period before we can get reassessed ? or can we book one shortly after ?
4) The wireless bit in your article is interesting, our CDE is hosted at a 3rd party, does the PCI section focus on Wifi networks _directly_ connected to the CDE as in physically on the same datacenter ?
Thanks in advance and sorry for all the questions.
First, you need to define “tier 1”. If you mean your organization is a Level 1 merchant or service provider, you cannot do a self-assessment questionnaire (SAQ). Your organization must conduct an assessment that results in a Report On Compliance (ROC). That does not mean you have to hire a QSA to conduct the assessment, but someone from your organization will have to go through the Council’s ISA training.
To answer your questions.
1. Yes. GnuPG (GPG) is sufficient as long as you have procedures that meet the requirements of strong encryption keys and key storage under dual control.
2. Get a copy of the Open PCI Scoping Toolkit (http://itrevolution.com/pci-scoping-toolkit/). It provides the best explanation of how to properly scope an assessment. But yes, any hardware or software that directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD) is in scope for PCI compliance (aka Category 1 devices/systems). In addition, any hardware or software that is connected to Category 1 devices/systems are also in scope for PCI compliance (Category 2 devices/systems) because they could influence the security of the Category 1 devices/systems. In your example, the mobile phone is only in scope if it is under direct control of your organization, such as with a POS using Square on a mobile phone. Customer equipment is not your responsibility.
3. If you are judged non-compliant (organizations do NOT fail), then you are required to come up with a plan for remediating those areas of non-compliance and then getting re-assessed. That could be a matter of weeks to even months depending on the issue(s).
4. If your third party conducted their own PCI assessment as a service provider and covered ALL of the services provided to your organization, then you would rely on their Attestation Of Compliance (AOC) to cover their responsibility for securing wireless in their environment as other relevant requirements. If they did not do their own PCI assessment or they missed services provided to your organization, then your organization is responsible for assessing the service provider or the missing services as part of your PCI assessment.
I’m a level 1 merchant that has a QSA perform the assessment. As we change our infrastructure, we changed our web infrastructure for one of our sales channels to redirect to a third party payment site (iFrame). For this sales channel, we the merchant do not have any access to CHD nor do we ever type in CHD, meeting the SAQ A type requirements.
Our QSA is saying that we need to perform a full ROC even though we have minimized our risk to the controls of an SAQ A validation. I understand there are risks to the website still, but my point of view is it should not be in scope for the ROC assessment.
What is your perspective?
Whether you do a ROC or an SAQ is not determined by the size of your scope, it is determined by transaction volume. As a Level 1 merchant (6M+ transactions annually), regardless of scope, you are required to to perform a full assessment that results in a ROC. If your Web site is your only payment channel, then you will have a ROC that only covers those requirements in SAQ A with the rest of the requirements marked as “Not Applicable” with the appropriate reason documented. That said, the QSA is required to assess the Web site to make sure that it in fact is using an iFrame that removes it from scope.
My company is going through the first PCI compliance with SAQ D and is implementing a lot of controls for the first time. We can’t satisfy a lot of requirements for history data/evidence, like samples of change control approvals, log review history/evidence, last several vulnerability scans, last quarter log review, etc.
Should we assume that for the initial PCI compliance, once we place the necessary controls in place before filing the compliance report, we are meeting the requirements? If so, how can we answer those requirements (not in place, in place, or not applicable) ?
Thanks.
If this is your first assessment, then that needs to be taken into consideration as far as evidence is concerned for your new control environments. The Council specifically calls that out for vulnerability scanning, but not for other requirements such as in 10 for logging and the like. Your new controls need to be functioning for a period of time, at least a quarter or more. You should then mark the requirements as “In Place” but then comment that they have only been in place since whatever date.
Well said brother!