PCI DSS: The Next Generation
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
PCI DSS is going through a generational change. That change has nothing to do with the upcoming release of PCI DSS version 3.0 this fall. Instead, the generational change is in the security professionals I work with everyday, the people who are managing their organizations’ PCI compliance. Most of these professionals are very qualified, but they are new to their job and often also new to PCI.
One result of this generational change is that I am being asked some of the same questions I was asked five or more years ago. The questions range from whether pre-authorization data is in scope (treat it like it is) to the feasibility of E-mailing card data (a seriously bad idea) to what constitutes effective network segmentation (think “air gap”). Fresh perspectives are always welcome, so the implications of this generational change for merchants and QSAs alike are generally positive. But with new compliance staff and assessors come fresh challenges and approaches that can impact every merchant and service provider.
With the release of PCI DSS version 3.0 this fall, the standard will be about seven years old by my calculation. Seven years is a lifetime—or maybe a couple of lifetimes—in the world of technology and data security. A great example of this fact is the PCI Scoping presentation the PCI Security Standards Council staff made at the recently completed RSA Conference.
The PCI Council’s presentation was very good. But to someone who has been in the PCI trenches from the beginning, it didn’t break much new ground. As it turns out, the presentation didn’t have to. The scoping principles described differed little from what could have been presented anytime in the past few years. What was new was hearing some of the same questions from the audience and in the conference hallways that I first heard in 2006.
That fact tells me more merchants are, or should be, taking a fresh look at their PCI scope and not just accepting what they used the previous year (and may have been defined by the previous PCI team).
Let’s start with network segmentation. The point made in the PCI Council’s presentation was that for PCI purposes, network “segmentation” means “isolation.” 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. 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.
A merchant’s next-generation PCI team must consider each year the infrastructure and include systems that provide, for example, antivirus updates, patching and Internet domain name searches. A next-generation PCI team leader may not be aware that this issue of “connected to” was settled long ago and that a firewall—even a properly configured and maintained one—is not sufficient to achieve network segmentation. The result of such a misunderstanding could be incomplete scoping and increased risk of a reputation-damaging and expensive cardholder data breach.
Pages: 1 2
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 :)