At various times over the years, the Council has repeatedly told QSAs, Participating Organizations (PO) and anyone else that has asked questions about statements in the Information Supplements the following.
“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”
So what are the point then of the Information Supplements?
Boy is that a good question. As a QSA, I often ask myself that very question after some of the inane conversations with clients and prospective clients regarding Information Supplements and their supposed “guidance”.
The first thing everyone should remember about Information Supplements is that they are developed and written by a committee at the suggestion of the Council, POs or as part of special interest work groups. These committees are made up of personnel from interested POs, QSAs, ISAs, vendors and anyone else willing to participate in their development. They are edited by a representative from the Council and reviewed by the Committee and are then submitted to all POs, QSAs and ISAs for review and comment. Similar in concept to the development and review of RFCs by the IETF.
The other key point about Information Supplements are that they are developed to give QSAs, ISAs and organizations ideas and guidance on how best to appropriately meet the requirements of the PCI DSS and the Reporting Template testing. Again, as the Council has repeatedly stated, the Information Supplements do not replace the explicit guidance and testing requirements in the PCI DSS and the Reporting Template. They are merely suggests on an approach.
Yet time and again, QSAs and ISAs get these priceless documents tossed in our faces and are told we do not know what we are talking about. “The Information Supplement says …” is always put out there as the justification as to why an organization is doing something it should not be doing or as the rationale for why the organization is not in compliance with the PCI DSS. And we again are forced to explain that the Council never has said that an Information Supplement replaces the guidance and testing in the PCI DSS or the Reporting Template.
The first question anyone, and I do mean anyone, should ask about any statement in an Information Supplement is, “Does the PCI DSS and/or the Reporting Template explicitly say the same thing?” Those are the only two documents that matter and the only documents that your organization will be assessed against. If it is not explicitly called out in either of those documents, then it is not accurate and does not reflect the compliance requirements.
As an example. I was on a conference call recently regarding the Council’s Information Supplement on penetration testing. This supplement was issued in March, 2015 and is possibly one of the most confusing and contradictory pieces of “guidance” we have ever encountered. In fact, it has created more confusion than it has actually clarified. In my very humble opinion, the Council would be better off taking it out of circulation because of all of the trouble it creates for QSAs, penetration testers, ASVs and clients. It is possibly one of the worst written of the Information Supplements and, while people both on the Committee that developed it and externally supplied the Council with numerous suggestions for changes, those changes were not incorporated into the document. Why those changes were not incorporated is anyone’s guess. But we in the PCI community ended up with possibly the worst expressed and misunderstood guidance available.
As usual, the client was arguing over the scope of their penetration testing. I get the fact that organizations want to minimize costs and scope as much as possible. However when you listen to some security professionals arguments on this topic, you just wonder how they got to their positions as they argue over not testing systems and devices that are painfully obvious to be in scope.
And as also is usual, the first piece of confusion regarding scope is in Section 2, page 5, first paragraph after the bullets and states the following.
“It is not a requirement to test from within the CDE to the servers inside the CDE; and testing exclusively from within the CDE perimeter will not satisfy the requirement. However, when access to the CDE is obtained as a result of the testing, the penetration tester may elect to continue exploring inside the network and further the attack against other systems within the CDE, and may also include testing any data-exfiltration prevention (data-loss prevention) controls that are in place.”
One would think that to any reasonably intelligent information security professional, the first part of the sentence, “It is not a requirement to test from within the CDE to the servers inside the CDE;” would be considered a pure line of garbage. Never mind that none of the recognized penetration testing methodologies ever suggest such an approach. But people arguing never consider that fact. Nope. The people arguing are so focused on cutting their PCI compliance bill that it does not matter that the statement is pure and unsupported garbage. It is considered the gospel truth. Otherwise, why would the Council allow such a statement? Good question. We have asked the Council that question and the answer back is? You guessed it.
“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”
Again, never mind it is in no way supported by the guidance provided by the PCI DSS for requirement 11.3 which says:
“The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks.”
But argue that point they do even when you point out that arguing this point is basically arguing that any attacker would stop at the perimeter of the CDE and would go no further.
Seriously? If you believe that fact, you must also believe in Santa Claus, the Easter Bunny, the Tooth Fairy and any other of the multitude of mythical fictional creatures. Or you are just lying to yourself and are in serious denial about your organization’s security posture. But argue on they do.
Then you pair that to the second part of that first sentence of this paragraph that says, “… and testing exclusively from within the CDE perimeter will not satisfy the requirement.” Just adds to the out of scope argument.
As I point out when bitch slapped with this terrible writing, if you go back and carefully re-read the second part of the first sentence, what it points out is that penetration testing from only inside the CDE is not sufficient to meet the penetration testing requirements of the PCI DSS requirement 11.3. In no way does that sentence say or even further imply that the CDE is out of scope. It is actually saying that penetration testing should be done from within the CDE, but that penetration testing only inside the CDE does not meet 11.3. But people will still argue that the CDE is out of scope.
That the CDE is in scope is further supported by the definitions of “critical systems” from section 2.2.1 of the document which defines that not only are systems within the CDE in scope, but also those that are outside the CDE but could affect the security of those systems inside the CDE (i.e., what the Council and the Open PCI DSS Scoping Toolkit refer to as “connected to” systems). However, people arguing over scope rarely, if ever, tie these two section together and then argue that because they are in separate sections they cannot be possibly together even though the entire document is about only one subject, penetration testing and requirements in 11.3 of the PCI DSS.
So before you go off telling your QSA or ISA that the Information Supplement says something. Think about what the information supplement says. Is the guidance from the Information Supplement even implied in the PCI DSS? Read the guidance in the PCI DSS and the testing procedures from the Reporting Template. If the PCI DSS or the Reporting Template do not explicitly have the same language in them that the Information Supplement has, then the Information Supplement is merely a suggestion.
And if the guidance from the Information Supplement does not make sense, pull your head out of your posterior and use some God given common sense. Ask your QSA or ISA to explain it, before going off halfcocked and thinking that someone could actually think such things made sense.
But again, why would the Council allow such statements? Good question. We have asked the Council that question and the answer back is? You guessed it.
“Information Supplements only offer guidance to organizations and do not replace or supplant anything stated in the PCI DSS.”
Clear as mud? You bet.
But what did you expect? It is PCI.
For all of you in the United States, have a happy and safe Thanksgiving holiday.
PCI Guru 
They really do need more guidance on the internal pen testing. Lets say you do need to test inside the CDE, where do you test from? Do you test over the vpn? Do you pick a random server to simulate a system compromise? Do you need to test from all servers just in case any of them ever get compromised?
My preference is to test from outside the CDE to confirm that the controls are in place and functioning as well as to prove inbound CDE segmentation. Then test inside the CDE to make sure that the devices in the CDE are properly configured and secure as well as test outbound CDE segmentation. My rationale for that approach is to know what an attacker would “see” if they got inside the CDE. That way you can shortcut your analysis in the event of an incident because you should then know the likely scenarios an attacker would use.
I am not sure council can (or even should) clarify these questions and keep the guidance generic enough to be applicable to all merchants and service providers. There are many other questions that can be asked but it is not the council who should be providing the answers: should ARP Spoofing be used in production environment? Should reverse hash lookup be attempted? Should assessor (Penetration Test) create accounts as part of the assessment in production environment?
Take VPN for example – there are VPN solutions that simply route the traffic and there are VPN clients that “shape” traffic. So can you perform internal Penetration Test over VPN? Depends…
As a QSA, I work with my clients to identify the scope (target) of the Penetration Test and work with them to establish the required depth and nature of the assessment (baseline). Then, based on the Penetration Test report (executive summary, methodology and identified vulnerabilities), a QSA should be able to confirm if PCI DSS requirement is satisfied or not.
When it comes to defining what is “Penetration Test” – it is not running Metasploit Pro by a system / network administrator with 18 years experience managing environments. The assessment (Penetration Test) has to be performed by someone who has dedicated his / her career to evaluating the security of systems, and has the knowledge and experience to perform such evaluation. That entity (internal employee, external contractor, firm, etc.) should be able to clearly define the rules of engagements and elaborate what is possible and what is not.
Without knowing the details of the CDE environment and nature of the implemented security controls, I would be very careful not to position my answer as “definitive guidance” – so here are a few pointers:
– PCI SSC defines internal PT as assessment conducted from within corporate environment segment(s) that have legitimate access to CDE. That is the bare minimum! However, I strongly encourage clients to conduct some form of internal assessment (vulnerability scan or a thorough Penetration Test) from within CDE to ensure the environment is secure to withstand intrusion attempt or data leakage in case of internal perimeter (segmentation) breach.
– In segmentation is used, internal Penetration Test has to include an attempt to access the environment (CDE) from “other” internal segments that should not have access to CDE. Here, the client has to work with a QSA to identify which segments should be selected to represent the internal corporate environment (if sample is acceptable at all) and what is the depth of the acceptable assessment.
I will never put a pentester inside of my CDEs. My CDEs don’t even the share the same Internet and DMZ firewalls as my corporate environment and I don’t have PCs in corporate directly accessing my CDEs, so I don’t have an “internal environment” most people think of.
Then you are NOT complying with the PCI DSS. 11.3 requires that ALL in-scope devices and systems be penetration tested – period. Your CDE is in scope because it is the CDE and therefore it must be penetration tested.
So if your CDE is in an AWS VPC with strict security groups setup limiting inbound and outbound access for each instance, are you expected to do a penetration test from every server to every other server?
Also, with the CDE being in AWS with no lan connections, is there really any segmentation to test?
If those virtual devices are in scope, they are supposed to be penetration tested according to requirement 11.3.
As to your first question, I believe you are referring to making sure that segmentation is in place per 11.3. What you need to prove is that the network segmentation does in fact logically segments in scope systems/devices from out of scope systems/devices. You can prove that by running an Nmap scan from inside of the CDE to the outside of the CDE. The results should correlate to your firewall rules that segment the CDE. If they do not, then your assessment’s scope is wrong.
This subject certainly does seem to stir up emotions, a lot of emotive words being used in both the original text and the responses 🙂
Surely the whole point though of a penetration test, internal or external. and they intent of 11.3 is to show whether or not someone can make their way from an out-of-scope environment into a in-scope one, that is, penetrate your defences to your CDE. If you start the test from INSIDE there, that doesn’t tell you that at all, and the wording in the info supp is pointing that out. It’s not saying that you can’t carry on to test from inside the CDE if you managed to break your way into there – of course you WOULD continue in that case (and I think the info supp does say as much somewhere). It’s also not saying that the inside of the CDE is not in scope, in fact the very opposite.
This seems to make perfect sense to me?
If your CDE is truly isolated and it lives in a dedicated data center, the out-of-scope environment is the Internet. If the tester can’t break thru the Internet defenses, game over. If the penetration is successful then by all means go ahead and try to obtain some trophies. My point is, one has to logically break in first. What is the point of allowing the tester to perform testing from within the CDE? Don’t they have to logically or physically get in first? Perhaps if the third bullet under Requirement 11.3 was better defined?
“Include testing from both inside and outside the network.”
Alright, then. Define “inside.” Physical or logical? Define “outside.” Again, physical or logical? Define “network.” What network? Does the CDE reside in a dedicated data center or does it share rack space with the file and mail servers?
Along these lines, the more security defenses one has inside one’s CDE the better: For example:
1. Encrypt inflight CHD between CDE systems. I know; don’t lecture me. Not required on non-public networks. Requirement 4, especially in the context of MPLS circuits, gets me going almost as much as Requirement 3 does and spent gunpowder. I’ll save that for another rant.
2. IP restrict communication between CDE systems with software or appliance-based firewalls.
3. Disable all unused I/O ports on CDE systems.
4. Install intrusion prevention mechanisms on CDE systems.
5. Disable all unused ports and management ports on CDE switches and routers.
6. Implement a two-person-control for all privileged, logical access on CDE systems. Password split knowledge, split 2-factor authentication, or some other split scheme.
7. Implement two-person-entry controls requiring two authorized persons to gain entry into a CDE data center.
8. Security culture. Is it religion or checkbox driven? Is the secretary granting the QSA’s unescorted access into the CDE data center? Most QSAs will have already assessed the security awareness culture within the first hour of a PCI DSS audit.
I have always worked from a two phase perspective of penetration testing. The first phase of testing is done from the attackers perspective of what can they actually get to and compromise and how far can they go given the current security configuration. monitoring and other controls. The second phase is a penetration test of all of the gear that did not get tested in the first phase assuming that devices were protected such that the penetration tester could not reach them or test them fully or appropriately. The report from the first phase is the “official” report for the QSA and anyone else working on governance, risk and compliance (GRC) assessments. The second report is for the security team to evaluate and determine updates, mitigations or changes based on the results. The results of both reports need to be addressed in some form whether that is through patching, updates, mitigating controls or other methods.
If your mindset is that you will get hacked and it’s only a matter of when, then limiting the potential fallout of a compromise is just as important as not getting compromised in the first place. You might be super unlucky and get hit with a zero day you had no chance of defending against.
Back in March we changed a bunch of our IPs and I thought we needed to get them whitelisted with a famous British company who have “Royal” in their name. It turned out that we didn’t and that we could already access their servers from our new IPs so I assumed they had updated their protocols or something. Then in October all our new IPs were blocked and while they didn’t admit it it was obvious that part of their firewall had been off or reset for 6+ months before anyone noticed. Such accidents are easy and make your pen testing results instantly invalid.
That has been my position all along. In the “isolated CDE” scenario, you have to get in from the untrusted network first. And in my case the untrusted network is the Internet.
If and only if you get in, please do continue your fun inside my CDE. But even then you would have to deal with tertiary firewall zones controlling all internal/external peer communications by protocol and direction. If I put you inside my CDE where everything is in scope, what exactly are we trying to accomplish here? The “one size fits all” approach might work in most environments, but I’m not like most and therefore I suppose in the eyes of some, I’m not compliant with 11.3 because I don’t have an internal environment in the classic sense.
Again, the Council needs to properly define the terms “segmentation” and “isolation.” Question. If I’m doing segmentation inside of my CDEs where all CDE segments are trusted, does that mean I have to test that segmentation? I think not.
I agree. Plus I wouldn’t want to run a NMAP scan from inside of my CDE to the outside? I have no interest in mapping the Internet :-]
Technically, you should not be able to reach the Internet from your CDE under the PCI DSS.
I have a few comments because nothing else PCI gets me going more than Requirement 11.3. I agree the Information Supplement is rubbish and it should be pulled down and never be allowed to see the light of day again. This very subject has been the epicenter of some heated battles I’ve had with some moronic QSACs and their QA departments. In the end they received a silly piece of paper from me that stated an internal penetration test was completed…for their Requirement 11.3.2 checkbox. It is time to properly define the terms “isolation” and “segmentation” in the Payment Card Industry just as “masking” in Requirement 3.3 and “truncation” in requirement 3.4 have their place.
The term “isolated” is used once in PCI DSS v3.1 [page 11] and six times in the Information Supplement, but the first time it appears as “isolated (segmented),” implying the terms have the same meaning. And the Information Supplement addresses the testing of segmentation, but does not distinguish between the two terms. If you think you truly understand CDE isolation, please skip the next paragraph.
An isolated CDE should live on its own set of public and RFC 1918 compliant IP address space, have its own set of Internet firewalls, have its own set of IDS/IPS systems, have its own set of DMZ firewalls, have its own method of 2-factor remote access, and so on, and there should be no on-premise wires connecting the isolated CDE with the corporate network. And to clarify, no PCs outside of the CDE should have a direct route to a CDE system, let alone the 2-factor beachhead. There is nothing an isolated CDE should share with the corporate network. Still with me? Yes, it’s expensive and a lot more work. All of this can be tested, of course, but the testing would not be under Requirements 11.3.2 or 11.3.4 because there is no “internal environment” to test from, yet it is sad that I have had QSAs tell me an internal penetration test is required. When I asked them where I should perform internal network penetration testing from I got, “Install your penetration testing tools on your CDE network,” or “Plug into an open port on a switch.” Very sad. And on the latter, if there are unoccupied ports on a switch in your CDE that haven’t been disabled the network admin should be drawn and quartered! Some QSAs get it and some QSAs don’t get it. Those QSAs that don’t get it should find a new line of work.
Another challenge with Requirement 11.3 and attempts to clarify it with Information Supplements is the “one size fits all” approach and we all know how that works out. There are CDEs living in a flat network and there are CDEs that are completely isolated from the corporate network and there are countless combinations in between. It is shameful that Requirement 11.3 and the Information Supplement do not address isolation as well as they do segmentation. Why not clear up the mud in Requirement 3? After all, there is a “Guidance” column in the PCI DSS. Use it instead of trying second guess the inadequacies of the technical writers’ intent in Requirement 3.
The PCI Data Security Standard Lifecycle is also a farce to because I have submitted Requirement 11.3 feedback on isolation versus segmentation. No change. I’ve been very vocal on the open mic [when it was available] at PCI Community Meetings. No change. I have spoken to high up people at the PCI SSC. Crickets! At least I have this forum and if you’re reading this piece it got through the censor process. Thank you, Jeff!
When contemplating a Requirement 11.3 methodology, one should also write it down and get their ISA/QSA’s buy-in/approval before potentially going down the wrong road, wasting time and money. That would also prevent a lot of headache come PCI DSS audit time. Section 4.1 in the Information Supplement alludes to QSA involvement, but it’s not made brutally clear.
Clear as mud is an understatement. Way to go PCI SSC!
I feel this post was written in anger and anguish!
DUH! Tired of arguing with people over stupid issues. People treat PCI as a check box because they can.
LOL. Patient my friend. Today it is Requirement 11.3 “clarification” – tomorrow it will be Requirement 6.6 “clarification”.
The equivalent documents from the EU would be Directives and Explanatory Notes. The Directives often amend each other and are a neverending web to read whereas the Explanatory Notes bring everything together with references to the sections of Directives you need to read. They also usually list out many example situations which can help you understand the spirit of the Directive and prevents the less honest from using pedantic wordplay to dodge laws. However ENs always start out by saying that they are not legally binding (because they’re not the law, only the Directives are).
But then I have the opposite problem as you: I can never get anyone to read the ENs! People see a 100 page document that starts off “this document is not legally binding” and then tell me there’s no point reading it if it’s not binding. So I tell them to read the Directives instead and they complain that only a lawyer could understand the Directives and that I’m expecting too much from them! JFC! (If you know your sector properly you should be able to understand the Directives regardless).
This is all part of a trend I’ve noticed where nobody in tech is willing to “do the details” anymore. Nobody will read docs unless they’re a pretty web page and organisations publish docs full of contradictions and half the specifics missing.
Pretty much all the PCI documents could do with being rewritten, including the wording of many questions. Has anyone ever taken the council to court to test their statements?
Great write-up, Jeff! Sadly, I have also encountered the dilemma associated with Information Supplements. I concur that any poorly contrived recommendations that offer even the appearance of detracting from the Requirements is unhelpful and counterproductive. Hopefully they take your admonition to heart and take greater pains to avoid such confusion in the future. Even more hopefully, perhaps they will revisit the existing information supplements and endeavor to make them less imprecise.
And a Happy Thanksgiving to you and your family as well! 🙂
I couldn’t have said it better myself. I was on the committee when it first started and none of my edits made the cut. I have a background in both pen testing and PCI so I thought I was making a difference but that didn’t happen.
Couldnt agree more that this has caused and is still causing debate and confusion. It I remember correctly (could be wrong) in none of the worked examples within the supplement does it indicate/state full testing being done on devices within the CDE which only adds to the issue.
Clear as mud… tnx for the explanation. Happy thanksgiving.