This is page 2 of:
PCI DSS: The Next Generation
Another, more subtle point made by the PCI Scoping presenters was that just because a system is in the merchant’s PCI scope, does not mean that every single PCI DSS control necessarily apples. There are roughly 280 controls in PCI DSS. A patching server, for example, will not store, process or transmit cardholder data, so many of the requirements (e.g., Requirement 3, Protect Stored Cardholder Data, among others) will not apply. Next-generation PCI team members need to know they have the leeway to consider carefully each requirement and to determine whether or not it is applicable to their unique situation.
This is not to say merchants may take a risk-based approach to PCI. The difference may seem subtle, but merchants do not get to pick and choose between which PCI requirements they will apply and which they will skip. That approach has long been declared taboo, and the next-generation PCI team needs to understand that and move on.
One issue a U.S.-based next-generation PCI team will face very soon is the impact of the migration to EMV chip cards. I was recently asked whether the introduction of EMV chip cards in the U.S. market would not be the silver bullet that eliminates the need for PCI compliance. Unfortunately, I had to disabuse the questioner of that notion immediately. The answer is that EMV is about authentication, not confidentiality, and that PCI will not go away. Those of us who have been in the industry for a while know we resolved this question a long time ago. The next-generation PCI team was not around to hear the answer, however.
I hope the next-generation PCI phenomenon will produce one very particular, positive result: a fresh look at the organization’s PCI governance structure. Fresh people and fresh ideas present opportunities to improve how merchants and service providers manage their PCI compliance for the 364 days between yearly compliance validations.
For example, does your next-generation PCI team represent both the IT and the business side of the organization? Do the marketing and new product areas get their mobile commerce questions answered? Does the next-generation PCI team understand the impact of the new Wi-Fi system that the warehouse or fulfillment department is about to install? Are the EMV lessons from the organization’s European or Canadian operations—and the PCI compliance lessons from the U.S. operations—shared with the next-generation PCI team?
The emergence of the next PCI generation presents many more opportunities than challenges. Yes, it makes some people (like me) feel old or possibly frustrated at answering the same questions we heard five years ago. The upside, however, is the opportunity to take a fresh look at the organization’s PCI scope and PCI governance. These benefits will far outweigh any costs.
What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me.
-Marc
March 25th, 2013 at 9:59 am
So true. I run into the same questions all the time from merchants. The biggest issue after all these years is still surprisingly- education. What is PCI DSS and what does it mean to me? PCI fees on merchant statements served as a wake up call to a large number of merchants. But for others, I call it the ‘busy syndrome’. As a result of economic changes, companies are operating lean and employees take the stance of ‘too busy’ to look at that right now.
Forcing credit card processing sales people to be responsible would probably improve compliance. What if the salesperson had compensation withheld whenever a merchant is known to not be PCI Compliant?
From the merchant side, I rarely find companies have someone who has specific responsibility for PCI Compliance. Maybe it’s time to update employee job descriptions to include this function? HR folks comments?
I’ve also found that some of the worst offenders are companies that have assigned someone a general ‘compliance’ role. In those cases PCI seems to take a back seat to other issues.
PCI DSS next generation presents a great opportunity to educate merchants, but I’m afraid if companies don’t start adding PCI to job descriptions, the problems will continue for another 7 years.
March 25th, 2013 at 10:09 am
I would expect this turnover to continue, and wonder what resource would be best to refer the new security team to for a thorough PCI orientation?
March 25th, 2013 at 7:18 pm
@James- I recommend everyone use the the official PCI Council web site at https://www.pcisecuritystandards.org
March 25th, 2013 at 9:04 pm
A firewall is not network segmentation? What is? How do I keep my upstream ISP’s router out of scope?
March 26th, 2013 at 8:47 am
Thanks for the great comments! It looks like others are seeing the same thing as I am, which is always a little scary.
@Christine, you raised a really good point about putting PCI compliance in somebody’s job description and — extending your idea — actually making compliance part of that person’s annual review. What a concept! I would second your response to James about the PCI SSC’s training. I do a lot of training, but if somebody is going to be responsible for PCI compliance, then an Internal Security Assessor (ISA) credential is pretty important, and the other key staff should at least attend some PCI security awareness training and maybe even go for the PCI Professional (PCIP) credential. The particularly attractive part of the PCIP is that it stays with the individual, not the company.
@Bob, while a properly configured (those two words are pretty important) firewall can effectively limit traffic into/out of a network segment, it does not isolate it necessarily. As for your ISP question, if you share cardholder data with them or if the ISP can affect the security of your payment card transactions, then the ISP may well be a PCI Service Provider, and they would be in your scope as such. You would need to be sure to include them in your Requirement 12.8 (all four sub-sections) response.
Thanks again for the great comments and discussion.
Walt
March 26th, 2013 at 6:08 pm
Ok, I can understand the “properly configured” qualifier. It really sounded like you were saying that a firewall CANNOT be segmentation or isolation. You said:
“It does not matter if there is a firewall controlling the access. It doesn’t matter if the connection is only for “a little while.” If a connection is possible, then the network is not segmented for PCI purposes and all the devices are in scope.”
which seems to make it pretty clear that a firewall isn’t good enough with no mention of a “properly configured” firewall being sufficient.
You also say in the above article:
“That is, if a system or device can initiate a connection into the cardholder data environment (CDE) or receive a connection from the CDE, that system or device is in the merchant’s PCI scope.”
So if I’m running an e-commerce operation and my customer at home in his pajamas ordering a widget from my site can talk to my CDE (which he has to in order to submit his credit card info) his PC is in scope?
Or my monitoring system which connects to snmpd on my order taking internet facing webserver is in scope?
I can understand how an Active Directory or LDAP server which handles authentication for machines in the CDE would be in scope but to say anything which can connect to the CDE and anything which can be connected to from the CDE is in scope is greatly overstating the problem and renders lots of people’s work to reduce scope via network segmentation and firewalls moot.
March 27th, 2013 at 11:33 am
Hello,
As an ISA and a 20+ year Information Security Veteran I have to take issue with your article. The main point of contention is that segmentation, as taught by the PCISSC is valid if there are properly configured Firewalls, routers and properly managed ACLs in place.
The option of a true Air Gap, i.e. a physically disconnected network is the ultimate segmentation but by no means the only way to segment. Firewalls and routing, switches and ACLs are all very valid ways to do so.
PCI DSS V2.0 “segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network”
And
“At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not.”
And
“1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—to determine that there is no direct access between the Internet and system components”
All of these items mean that the assessor you or me must make a decision to the effectiveness and the adequacy of the segmentation.
Appendix D: of PCIDSS V2.0 is useful here with a flow chart.
Regards
Stephen
March 28th, 2013 at 4:07 am
Bob and Stephen,
Thanks for the comments! This is a good discussion. I think we all agree that a properly configured firewall can certainly achieve segmentation (i.e., isolation) for PCI DSS purposes. Unfortunately, in the real world, firewalls often permit inbound or outbound connections, and therefore they do not achieve the desired segmentation and scope reduction. For example, there may be “holes” in the firewall to permit patching, AV updates, etc.
My point is that if the rules on a firewall permit any access by another system for whatever purposes, then that other system is not segmented (isolated) from the PCI environment, and that other system is in your PCI scope. By permitting an inbound or outbound connection to the cardholder data environment (CDE), you expand your PCI scope.
It all comes down to the actual specification of the firewall ruleset or router ACLs. An explicit “Deny All” rule achieves segmentation for PCI. About anything else risks expanding scope.
Walt
March 28th, 2013 at 11:48 pm
About the next sentences:
if the rules on a firewall permit any access by another system for whatever purposes, then that other system is not segmented (isolated) from the PCI environment, and that other system is in your PCI scope. By permitting an inbound or outbound connection to the cardholder data environment (CDE), you expand your PCI scope.
If a system or device can initiate a connection into the cardholder data environment (CDE) or receive a connection from the CDE, that system or device is in the merchant’s PCI scope. It does not matter if there is a firewall controlling the access. It doesn’t matter if the connection is only for “a little while.” If a connection is possible, then the network is not segmented for PCI purposes and all the devices are in scope.
So, one example: what if my organization has implemented tokenization, therefore three information systems receive and use tokens instead of PANs. These three informations systems are in different subnets (VLAN) isolated of the Tokenization system and Token Vault (Card Vault) through one firewall with strong access lists, only allowing one tcp port for the three information system pull, or the tokenization system push the tokens toward the three information system.
If the two sentences are true, my three informations systems seemingly isolated of the CDE (Card Vault and Tokenization System) keep on the scope. Then, what are the benefits with tokenization, if the systems with tokens still are in the scope, in spite of the fact that i used firewall with strong access list only permitting the necessary services.
What happen with the concept of strong access list learned in the ISA or PCI QSA training. Where is clear that “segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists”
The PCI SSC unfortunately close some years ago the SIG about scoping, and the last year make call of inputs about Scoping and segmentation, but we don’t know the conclusions.
Inputs and perspectives on the following:
1. What do you think constitutes adequate segmentation (isolation) for the purposes of removing system components entirely from PCI DSS scope?
2. What controls do you think should be in place on or around a system that is connected to the CDE (and so is in-scope for PCI DSS) to prevent that system from bringing other systems into scope?
3. What examples have you seen where additional controls are implemented on in-scope system components to reduce the PCI DSS requirements applicable to those systems?
June 5th, 2013 at 11:14 am
Hi
An old thread but one I thought I’d add my 2 cents for what its worth.. :)
I always view this as the CDE and other in-scope items (i.e could affect the security of the cde).
For example if I do have a properly configured firewall/acl etc and one of the ‘justified’ rules outbound is just for ping monitoring stats… am I that bothered? it’s in scope and maybe worthy of a look but I doubt I would heap lots of controls on it (and lets face it the majority of controls should ‘hopefully’ be default be on most machines), now contrast this with a box which has an inbound justified connection, now same again.. its in scope (not processing/storing etc else it would be inside the cde), am I more interested now, yes as it’s definitely an attack vector so I would look to see what role the box was playing and put what I thought appropriate controls would be around it.. I wouldn’t drag everything else in around it as the controls that hopefully I apply would mitigate it against that…
The extreme say for example would be an AD controller, if this was outside the CDE and was used for authentication then even though this outside the CDE I would throw the book at it near enough for controls and treat it like it was inside.
In my mind it really all depends on what role the outside connections are playing as to what controls are applied combined with an understanding of the overall architecture,a bit of pragmatism, realism and faith in whatever floats your boat :)