I have had a couple of discussions recently regarding what constitutes good network segmentation. Apparently, my original post was just too cryptic, so I’m going to use some examples in this post to hopefully clarify where people are going wrong.
The PCI DSS gives very little guidance on network segmentation. In fact, the only statement near a definition says. “Network segmentation can be achieved through internal network firewalls, routers with strong access control lists or other technology that restricts access to a particular segment of a network.” But those are the mechanics of network segmentation. This definition does not specify or illuminate the additional controls required to ensure segmentation which is why I wrote the original post.
In my first example, the network in question is segmented by VLANs. The cardholder data environment (CDE) is contained in one VLAN and there are another eight VLANs defined. All VLANs are internal and none face the Internet. Access control lists (ACL) have been implemented to control the communications between the various VLANs and the CDE VLAN. Monitoring of all of the VLANs has been implemented through a variety of methods including network monitors, host monitors and system/event log monitoring and analysis. Network administrators monitor consoles that bring up any critical alerts that could indicate a potential attack or compromise. This definition sounds pretty good does it not? The problem is that it is all in the details and the details tell a different story.
In reviewing the VLANs’ ACLs we determined that two of the VLANs have TCP and UDP ports 1 through 65535 open to the CDE VLAN. Whoa! Every port is open to the CDE VLAN from these two VLANs? Yes, that is correct. This is not what the PCI SSC thought was “strong access control lists.” In digging further, we inquire as to why this condition exists. We are told that, ”We were unable to determine what the applications needed to have open between these VLANs, so rather than break anything, we just opened everything to be safe.” To be safe? Safe is a term that has different meanings relative to each person’s view that uses it. In this case, because the two VLANs were internal, apparently the other VLANs were considered also ‘safe’.
But a lot of network administrators would point to the monitoring as the way they control things. Are you serious? I do not care how much monitoring you do. With every port open, that monitoring is going to likely generate enough false positives to make identifying the real threats like finding a needle in a haystack. And this was confirmed later on when we observed the network administrators that monitor the network. They were ignoring almost everything that came up on their screens. When we questioned them about this, they said, “We have tried to tune the alerts, but have not been able to significantly reduce the false positives. We get around 10,000 to 25,000 alerts a day. So we do the best we can to find the real threats.” The best we can? Security is not forgiving, let alone for people that are doing ‘the best they can’.
The moral of this example is that if you have every port or close to every port open, you cannot consider your network properly segmented. I do not care what the other controls are that you believe are in place. You have to be realistic. And justifying having all of those ports open has to be more than implying you were too lazy and did not want to make the effort to find the real answers.
My other example involves a network that does have a limited number of ports open between their CDE VLAN and their other VLANs, albeit there are quite a few open ports. They also have monitoring in place and their network administrators are very diligent in ensuring that alerts are addressed as quickly as possible. Unlike my first example, these folks are seeing around 300 to 500 alerts of which 10% to 15% are false positives. The problem is with their documentation. In reviewing the firewall rules that segment the VLANs we documented all of the ports open to/from the CDE VLAN to the other VLANs. We interviewed the Manager of their network management and administration department and inquired as to the business reason for each of the open ports. Of the 100 or so ports defined in the ACLs, they can only give us business reasons for about 20% of them. Heaven forbid they should document the reason in the configuration file, but there is no other documentation available. The Manager even tries to find documentation in the help desk system where they log all of their changes, but even after refining the search criteria, there are just too many records to sift through in our one hour meeting to find what we need. Not even proof that management knows that these ports are open, the risks that are involved with these ports being open and that management approved that these ports be opened.
The moral here is that documentation is the foundation from which you build. If you have a shaky foundation, you will have shaky security and are likely a candidate for a compromise and breach. This is why documentation is important. If you cannot remember why ports were opened, users were allowed access to data and other security relevant issues, how can you even think you are secure? The answer is you cannot be secure if you cannot answer basic questions.
But it gets better. This same individual earlier in our meeting had confirmed that they were the one that reviewed the firewall rules quarterly and showed us emails to prove that fact. Then as we are going through the CDE ACLs, they say, “Oh, that rule should be removed. It was for a business partner that we have not done business with in more than four years.” Now, do you think I seriously believe that you are really reviewing these firewall rules quarterly when you admit that a given rule should have been removed four years ago? We document four more firewall rules that should have been changed or removed. It is situations like this that cause a QSA to shudder and then wonder what other ugly things are under the rocks and just how far you need or want to dig to find them.
Our moral here is telling the QSA what they want to hear when you know you will have to contradict yourself later on. All it does is make you look incompetent. But this situation also points out a good point regarding the duties of a QSA in conducting their assessment. QSAs not only rely on interviews and documentation, they also rely on observations to ensure that organizations not only talk the talk but also walk the walk.
So what then is proper network segmentation? A properly segmented network is much more than just technology.
The foundation of a properly segmented network starts with the control triad of preventative, detective and corrective controls. Preventative network controls are going to be firewall rules and VLAN ACLs and any other controls that prevent or control access. Detective network controls are going to be related to the monitoring you implement. Monitoring can be real time and/or log analysis after the fact, but it should not be limited to just access to/from the CDE. Monitoring also needs to include monitoring the network traffic for anomalous traffic. Finally, you need corrective controls to ensure that any issues discovered with the preventative and detective controls are addressed as soon as possible. Corrective controls are usually generated as action items created from such things as the lessons learned from an incident response plan or findings from an audit.
Once you have decided on the controls you will implement, you then need to create documentation that supports those controls. For networks, the documentation that is key is to document every port that is open inbound to or outbound from the CDE environment. Each of those ports will have been formally approved by management with the risk presented by having the port open. And that risk analysis needs to include not just the port in question, but any other relevant ports, if necessary, as certain combinations of ports may increase or decrease the risk. This risk analysis is important for a number of reasons. First, it documents the basic analysis of risk and provides the rationale for having made a decision at that time. That documentation can also save you if a breach occurs as you can understand what the people were thinking when they originally opened the port and also understand potential methods that might have been used to cause the breach. This documentation is also important for the quarterly reviews as you can use the documentation to refresh your memory as well as assisting you in making changes to the rules if business conditions change. Yes, I know firsthand that documentation is the last thing anyone wants to do. But without it I will guarantee you will not remember six months or more down the road why you did what you did and for whom. And in the security business, it is that sort of knowledge that can mean the difference between being secure and being a target.
The next item that needs to be documented is the users, programs, services and organizations that have access to the CDE. In the case of programs and services, this should be tied to the aforementioned list of ports open. In a breach, this documentation will reduce the number of likely suspects of where the breach came from. As a result, you can see why it is important to limit the number of people, programs and organizations that have access to the CDE.
The final piece of documentation that needs to exist is what should be done in the event a problem or an alert is generated. If people do not know what their responsibilities are in regards to providing feedback, then alerts will be missed or ignored and problems may not be addressed as quickly as they should. Responses to problems or alerts should include detail regarding the conditions that created the problem or alert, the steps take to address the problem or alert and any issues that may have resulted from addressing the problem or alert. If the problem or alert is not addressed in the timeframe required, there needs to be an escalation process so that the problem or alert receive the necessary visibility of management should they go unaddressed.
I hope this provides the additional examples of network segmentation.
PCI Guru 
Hello. Congratulations for your blog. Your posts helped me a lot. I would appreciate a lot if you could help me with the following question.
One workstation access an internal webservice in CDE through VPN and controlled by a firewall. There isn’t jumpservers in this case because the access is only to this specific service. Is this workstation category 2b? If no, which category is? Another workstations in the same network but with no access to CDE are out-of-scope?
Thank you.
ANY device that directly connects to anything in the cardholder data environment (CDE) is also part of the CDE (i.e., Category 1) because you have no network segmentation such as a jumpbox separating the workstation from the server in the CDE.
Thanks to the use of the VPN (assuming it is encrypted), the VPN segments the workstation in the CDE from everything else. That said, any workstation when the VPN is not running could infect the workstation with CDE access, so one could argue that the workstation with CDE access should just be placed in the CDE.
Hello Guru,
In my case there is network segmentation from workstation and cde. They are in different subnets/vlans and the access is controlled by a firewall only to one specific port. Still in category 1?
Another question… Could be use the same Zabbix Server or a Antivirus server (servers in category 2) for CDE and out-of-scope servers? Could an out-of-scope workstation access this zabbix server, for example? Reading the ISACA’s doc I understood yes.
Thank you so much for your time and replies.
It sounds like your workstation would be considered a “Connected To” device which is how the Council defines Category 2 devices. You should read the Council’s Information Supplement on the subject so that you are using their terminology and not the terminology from the Open Scoping Toolkit which has been superceded by this document (https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf?agreement=true&time=1575360884428). However, the real determination of that will be based on your data flows of CHD and whether or not this workstation is in that flow.
The whole point of “Connected To” to to provide a network segment that can communicate to both the CDE (Category 1) and out of scope (Category 3) systems. So yes, servers in the “Connected To” segment can communicate to CDE and out of scope systems.
Hi Guru,
The out of band management VLAN comes under PCI-DSS Scope VLAN or not ?
The VLAN that you use to manage devices likely manages devices that are in scope for PCI compliance, therefore, it is also in scope for PCI compliance.
Hello,
This post is really helpful in understanding Segmentation. I have a question for you.
I am a service provider and my Client asked me to comply the environment with PCI dss. I have defined CDE which connects to internal network, internet and client’s managed router(in premises). My question is about client’s managed router which is housed in my company office but managed by the client publicly. Do I need to put firewall , router or layer 3 switch in between client owned/managed router and my CDE?
Would any of aforementioned devices comply in this scenario or I must install firewall specifically and define ACL’s?
Let me know if you need more clarifications.. Thanks
A firewall is the only device that the PCI SSC states provides the necessary segmentation, packet inspection and monitoring capability given the likely number of protocols being used.
Hello, we have our CDE hosted in the cloud (Amazon) and our internal network hosted in another provider, so that both networks are completely independent, no access from one to the other except for specific services (via VPN). If we allow remote desktop access from our internal network VMs to the CDE environment, would that make our internal network subject to full-PCI compliance?
Thank you very much for this blog.
They would definitely be Category 2x systems in the vernacular of the Open PCI Scoping Toolkit.
Assuming that RDP is configured to use only strong encryption for its connections AND that no one is keying CHD through their workstations to those systems, I could see them being only 2x and the rest of your network out of scope.
Hello, we have a debate on an issue as to compliance. The questions are we have Client A that their network is flat and the PCI affected devices are NOT segmented from the rest of their operating network, then we have Client B completely separate but we have multi tenant inventory servers that scan Client A’s devices and stores the information in a shared SQL server. We are implementing TLS 1.2 on all and using the FORCED ENCRYPTION for SQL.
1. Does their need to be two separate SQL servers one for each customer since it stores Client A’s scan results on it.
2. What other compliance issues would their be if us as the 3rd party has agents on their PCI devices scanning the inventory and then sharing the servers with other clients on our end?
What you did not share is whether or not your network is always attached to your clients’ networks.
Assuming it is, I would then assume that you have one or more scanners located at each client and are only feeding results back to your SQL Server. That would mean that your clients could firewall off the SQL Server from their network and control data flow between only the scanners and the SQL Server. I would also assume that the scanners have two NICs so that one NIC is pointed at the client’s subnets to be scanned and the other NIC is pointed back to the SQL Server and IP routing on the scanner is disabled. In that sort of configuration, I could then justify that the SQL Server is out of scope. However, you organization is not out of scope because I would also assume that you would have access to the scanners on site at your clients.
If that is not the case, then you could be a conduit for compromise for every customer you scan because it would be impossible to firewall you off.
Hi mate,
I was reading one of your comments to an answer around segmentation re as long as call centre terminals (where secure websites are used to enter card data) are secure (with anti-virus) etc. segmentation of the call centre network / agent terminals won’t be required.
I ask, as usually call centre agent terminals are part of wider networks of course using same security, directory services and business applications as the rest of the network. So what I get from that response is that as https encryption of that browser is segmenting the data from the rest of the network we don’t need personal firewalls to isolate those machines from the rest of the network, or bring in security services, etc. in scope?
also, if the underlying agent systems (included in scope) have av, firewalled off and secure vti’s are used to enter card data that goes directly to PSP – business applications are accessed via citrix then if we were to consider above where browser session used to enter card data is https and underlying box has av then rest of the network isn’t in scope, and segmentation etc. isn’t needed?
Appreciate your thoughts on it.
Many thanks,
Ash
Anything connected to PCI in-scope devices is also in scope, albeit potentially reduced scope as to the requirements they are required to be tested against. In your example, the directory services environment, applications and the like are all in scope for PCI compliance because the call center workstations are in-scope. Now, do those “connected to” systems/devices have to meet the same rigor as the workstations? That depends on how they are connected to the workstations. If those “connected to” systems have the potential to be a gateway to compromising those workstations, then they will have to meet the same rigor. If we have firewalls or port restrictions between the two, then I would say that those “connected to” systems could just meet the organization’s security hardening standards and controls (assuming those standards and controls are adequate).
In your Citrix example, the workstation threat is to a keyboard logger or memory scraper. In my very humble opinion, if the organization’s security hardening standards and controls are adequate, then I would let them coexist with any other PC on the network.
hi mate,
Thanks a lot for your responses as always – I have picked up your brains a lot on the scoping. I have a slightly different scenario here, mainly due to my lack of understanding of the citrix environments.
lets assume an application accessed via citrix launches a separate browser window calling an iframe (that is launched in that citrix session) – card details are entered and submitted to the PSP. The session is HTTPS – the underlying machine is considered to be the scope – what’d be your take on the Citrix infrastructure? (assuming that its not directly connected to that machine where chd is entered through local firewall etc.) – from key logging point of view would the citrix presentation servers etc. required to be part of the scope?
Many thanks in advance.
When using Citrix it depends on how your Citrix farm is configured. That said, most Citrix farms I have encountered being used to segment the PCI cardholder data environment (CDE) are all in scope for PCI compliance as are the virtual desktops that are used to conduct transactions. In addition, the desktops that access Citrix are also in scope, but they only need to meet “basic security” requirements not the full PCI requirements.
Hi Ash,
First of all, thanks for your invaluable posts!!!
I just want to make sure this sentence is 100% correct:
‘Anything connected to PCI in-scope devices is also in scope,…’
Isn’t it:
Anything connected to the CDE devices is also in scope,…
According to PCI DSS v3.2, page 10:
‘The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data.’
A VLAN with a explicit deny all firewall rule to the CDE, is still connected to the firewall, which is in-scope for PCI, but that VLAN is isolated from the CDE and might be out-of-scope.
What do you think about it?
Thanks and regards!
The bottom line is – if we do not draw a line somewhere, then everything is in scope. Technically both statements are accurate yet misleading. While anything that connects to an in-scope device/system is also in-scope, how much it is in scope depends on the risk presented by that connectivity. For example, an Active Directory domain controller is gong to be much more risky than a workstation in which data is entered through a virtual desktop (VDI) solution. Both are in-scope for PCI compliance, but one (AD) has much more risk associated with it than a workstation that is only a data entry point. This is why I tell people to read the Open PCI Scoping Toolkit to understand how to determine the risk of “connected to” devices/systems.
I’m trying hard to “isolate” a call center desktop PC from the rest of the network as the PC is used to input a small amount of customer’s CC#’s to a HTTPS website and also does normal PC functions for the PC user, like emails, accessing network drives, etc.
What I’m doing to is to have a DLP software installed on the PC to block any CC#s from getting out the PC even there are no CC#s stored on the PC. The DLP sends alerts to system admin and also logs any related activities to be regularly reviewed.
Does it justify the isolation so that any other system components this PC is accessing won’t be classified as inside CDE/scope?
Thanks.
Your PC is in scope because of the cardholder data entry function. The HTTPS causes that data entry to be isolated because the connection to the Web site is encrypted. As long as your build of the PC is secure and you have a way to recognize any malware that might attempt to be installed through anti-virus and white listing, you should be just fine.
Thanks. You gave me the confidence. I know it is all up to my acquirer to buy it. But now I feel more comfortable to present it. As always, you are my best PCI resource. Thank you.
Further on my issue, we are using InterCard teller to charge credit cards. I found InterCard is not on PCI certified vendor list. This is a trouble for us. Do I have to use SAQ D, or do I have replace InterCard before get PCI compliant? Thanks.
Just because a third party is not on the Visa or MasterCard certified service provider lists does not mean they are not PCI compliant. It just means that they didn’t pay Visa or MasterCard to be listed. Regardless of whether third parties are listed or not on the Visa/MasterCard sites, you need to ask all third parties for copies of their Service Provider Attestation Of Compliance (AOC). You need those AOCs to prove that they service provided to your organization have in fact been assessed for PCI compliance.
The other thing you need to know is that just because a third party is not PCI compliant or has not been assessed, does not affect your organization’s PCI compliance. However, if they have not assessed their PCI compliance, then you need to assess the services provided to your organization for PCI compliance as part of your assessment or get the third party to do a service provider PCI assessment. If a service provider is not PCI compliant, then you need to monitor their progress to achieving PCI compliance.
Thank you very much for the knowledgeable answer! That’s right, it ends up on who carries the “burden” :-(.
Hi, I have a similar issue like
“markikoy December 14, 2014 at 8:50 PM”
I have Micros terminals (with card readers) connected to its own Micros servers, and another application (say APP B) shares the hardware OS platform with the Micros terminal AND accesses Micros servers. Of course I have no way to isolate this APP B from Micros CDE, but it complicates the issue that I might be in SAQ D now. Is it true? How can I do/justify to stay in SAQ C?
Thanks.
I have never encountered a MICROS implementation that did not end up as an SAQ D because of the integration of the other applications. That said, it’s up to your acquiring bank to tell you that fact. You need to make your case to them and get them to decide.
Thank you! Looks like to I have to have a compen control to deal with that.
Hi PCUGuru, thanks for your blog which has a wealth of useful information for those trying to feel their way to compliance. I have a question around providing internet access in a corporate environment which I would appreciate your guidance on:
We have a branch office that has dedicated card payment PCs (the processing is done via an SSL webpage). The PCs aren’t used for anything else. These are all on a dedicated VLAN which is secured with its own firewall, with all the appropriate controls to ensure compliance.
My question is around how to provide internet access to this firewall, to enable the PCs to get to the external payment processing web portal – we are unsure whether we need to install a dedicated internet line (ADSL for example) connected directly to this firewall, or (our preference) route the encrypted outbound traffic over our WAN to the data centres where we have decent resilient internet access. Does PCI treat a “dirty” carrier internet connection differently to a “dirty” corporate WAN-based internet connection?
Thanks for any advice around this.
No, you do not need to have a separate Internet connection for your cardholder data environment (CDE). The Web page that uses TLS (hopefully they have dropped SSL) creates an encrypted tunnel that will segment the rest of your corporate network from the CDE.
Thanks PCIGuru. Specifically we are in CV-T territory, and we are being given advice that the “location” term in the SAQ scope statement “is not connected to other locations or systems within your environment” means connection to other locations regardless of encyption / segmentation, i.e. in our example, the CDE is connected via a dedicated firewall then our WAN to the other “location” of the data centre to provide internet access and therefore we cannot self-certify. My thoughts are that this is misunderstanding “connected” as the TLS encryption is end-to-end from browser to payment provider therefore it is not “connected” to intermediate locations, but there is no arguing with this particular person, who believes amongst other things that we should be worried about employees intercepting the encrypted traffic on the WAN and decrypting the TLS?
It all comes down to the risk and what your organization is willing to accept (within reason obviously).
I have some clients that believe as your colleague does that segregation can only be truly accomplished by firewalling such terminals from everything else. Unfortunately such practices are not always practical and can actually be less secure than just letting them be. But firewalling by itself is would not stop a POODLE attack if it were run from a terminal inside the CDE. There would have to be other controls in place to truly minimize the risk.
In regards to the risk of a man in the middle POODLE attack, depending on the version of TLS used, a POODLE attack could be run and it would be on the inside that such an attack would be most successful. However, if the TLS being used is v1.1 or greater, POODLE does not work, so there is no risk.
Thanks PCIGuru. So would you say that with the right controls and appropriate technical design, it is possible and reasonable to remain within SAQ CV-T compliance whilst routing the traffic out from the protected CDE using TLS 1.2 to the payment provider via the WAN and a central internet link? As the advice I have been given is that under no circumstances would this be acceptable and it would always push us into SAQ D. My reading of the scope, policy and intent of CV-T is that this design would be acceptable and indeed sensible. (And apologies for the duplicate post if my last attempt at this post did register and is awaiting approval!).
The TLS is what provides the segmentation of the network as an encrypted tunnel (i.e., IPsec and TLS) is consider a valid segmentation technique.
Your response to SaC was incorrect. TLS is an application layer type of symmetric encryption, that utilizes shared keys during communication for encryption/decryption purposes. TLS provides a means to ensure data integrity and prevent traffic sniffing, but it does not create an encrypted ‘tunnel’ and is not immune to MITM attacks. This solution would not provide adequate segmentation from the CDE and other parts of the network.
Hi,
Would it be possible to isolate the CDE from the rest of the network using just personal firewalls?
For instance, you have client machines that scan credit cards and send the data via an encrypted channel to a server for processing. Host based firewalls on the clients only permit connections to the server’s IP address. The host based firewall on the server only allows connections from the clients’ IP addresses. All other devices on the same physical network would then be unable to communicate with either the client or server.
I’m assuming this wouldn’t be enough as an attacker could potentially set their IP address as one of the in-scope clients if one of these clients is powered off.
It is not just personal firewalls in your example, but also encrypted communications. As long as those firewalls are monitored, this would segment those systems from the rest of the network.
Hello, Good article. I have a question pertaining to isolation.
We are implementing a new system that doesn’t process/transmit/store CHD. However the app-teir will interface to a DB server that does store CHD. My question is, will any type of device (firewall, proxy, etc) allow us to keep the web and app servers out of scope?
outside system – internet – f/w – web server – f/w – app server – f/w – db server
In this scenario, the outside system will transmit non-CHD to the web server. The web server will pass it off to the app server, and the app server will read/write to the in-scope DB server. No other system in the web(dmz) or app layers would co-mingle with in-scope systems.
Is the network segmentation enough? the firewall is a single ASA, not physical devices and each “layer” is a separate vlan. If not, would adding some sort of proxy between the app and db servers accomplish this?
Thanks.
The application server that connects to the database server (and any other devices that connect to the CDE) are always in scope. The reason is that they could be used as a beachhead to get into the CDE, so they must be secured as well and therefore assessed for PCI compliance.
Thank you. So is there any way to isolate the app server via a proxy of some sort or other device to move it one more “hop” from the CDE?
It still ends up connect to the CDE. The proxy does shield it, but the application server still could be used to penetrate the CDE.
I have clients going through all sorts of technological gymnastics to shrink their scope. Most of these “Rube Goldberg” solutions only make things more complicated and worse when just simply accepting the situation, hardening the server and monitoring it was so much simpler.
Nice article, but just wanted to check something with you.
If the company has 2 application (one is to be assessed for PCI while the other is not), both applications are sitting on different vlans but are connecting to the same dns server, then to the same database server (different database instance). Although the firewall rules restrict the traffic between the application and the dns server, it still cannot be considered a proper segmentation right? And with the limited resources, what do you think they can implement to reduce the scope? Thank you!
The question you need to ask yourself is, “What systems and networks are at risk of allowing access to the cardholder data?” The answer will guide you to what is in-scope.
Based on your limited description, you have support systems such as DNS, as well as the database server and your application servers. Regardless of the fact that the application servers are separated by VLANs, they connect to the same database server so the other application server could be used as a way to get to the database server and the other application server. To reduce scope, you would need to separate your databases and put non-PCI in-scope databases on a separate server in a different VLAN. Support systems such as DNS, DHCP, anti-virus master server(s), Active Directory and the like are all in-scope as they provide various services into the cardholder data environment (CDE) and could all be used to compromise the CDE.
Read the Open PCI Scoping Toolkit to understand the issues of “connected” systems.
Hi,
I’m trying to wrap my head around how segmentation would work in a hotel environment.
The receptionists (and F&B staff) that have the POS and chip & Pin devices on their PCs also have access to internal databases, company email and Internet. Would all computers that have POS and Chip & Pin devices have to be in a different vlan?
Also, what I don’t understand is that even if we segment the network, these users will still be able to access the internet and use services such as OWA (for email). So this would also be a risk.
It seems to be that these PCs (and therefore users) have to be completely isolated from the company network.
What am I missing?
Thanks for all the advice you make available on your site.
The hospitality industry is always problematic. Only front of house or customer facing POS should need to have points of interface (POI, aka card terminals). All other PCs should not need them and, since you are located in the UK, the customer must dip their card into the POI, so anything in the back office would not have a customer present so POI there would not be needed.
Regarding your applications, this is complicated by hospitality applications. Some vendors have done a great job of isolating their payment application from the rest of the application while others have not. Those that have isolated their payment application, anyone using it becomes a system indirectly in-scope (“connected to”) as opposed to a system that is directly in-scope. Systems that are indirectly in-scope need to be secure, but do not necessarily have to meet all of the relevant PCI DSS requirements depending on the risk they present. I would have to know a lot more regarding your environment before I could actually give you advice.
Hi,
Thanks for your quick reply
Hotel environments normally use PMS (property Management systems) and POS that are already PCI compliant. From that perspective compliance is already met, however PCs that use these applications, mainly Reception, although they are the only ones that have POI devices attached to them they are still part of the same hotel network as all other departments and share network drives and have email on the same server. As I understand from your reply all other computers are indirectly connected and must be secure. Is this enough or would a separate vlan still be necessary for Reception.
Or would monitoring and event logging of all POI devices be sufficient.
Also, would disabling OWA (Webmail) make it easier to be compliant?
Things are still not so clear for me.
thanks again
As I understand your explanation, your property management system (PMS) is the only system on property and all other computers connect to it. The simplest approach is just to treat everything as in-scope. However, how much each system is in-scope depends on the risk each device presents to the possible compromise of cardholder data (CHD) is what will determine how much effort is required to comply.
Being in the UK, you have EMV implemented, but that does not mean that the transmission of CHD is secure to the processor. Your operation is likely capturing sensitive authentication data (SAD) at guest check-in, so the PMS is storing the SAD for the length of a guest’s stay or one week whichever is less. I am assuming that your PMS stores the SAD encrypted and access to the SAD is restricted. Even though the SAD is pre-authorization data until you process it, it is still your duty to protect it and the card brands require you to treat it like CHD. As a result, anything that has access to the PMS is in-scope.
That said, any systems with access to the PMS but does NOT have access to the SAD/CHD needs to be securely built and monitored periodically to ensure it has not been compromised. Systems processing SAD/CHD would be in-scope for all relevant PCI DSS requirements. Access to the Internet and any browser-based systems such as OWA should be minimized and white listed.
In regards to network segmentation. As much as you try, you are never going to be able to use it as a way to reduce scope. From a risk perspective, if you want to segregate the systems with POI from those without, that is up to you.
The answer might be obvious but I am still quite unsure to the end.
I have computers that should be considered as CDE and computers that are not doing anything with CHD. But both of these computer groups use the same services: emails, DB, internal web servers. Does that mean I have to consider my whole network as CDE? As for example, non-CDE computers will be accessing DB, which is accessed from CDE, that means non-CDE networks gets in contact with CDE, and in case non-CDE network is compromised that holds a threat to CDE.
Thanks.
There are the systems and devices that compromise the cardholder data environment (CDE) that are definitely in scope for PCI compliance. Then there are the “connected to” systems that are also in-scope for PCI compliance. If any system or device connects to the CDE or could connect to the CDE, then those systems/devices are also in scope.
Based on your example, yes, your entire network is not segmented enough and is entirely in scope for PCI compliance.
Thank you so much for this blog and the bountiful information contained in it.
I have noticed that the wording has changed on segmentation.
v2.0 said “Network 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…the adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors, such as a given network’s configuration, the technologies deployed, and other controls that may be implemented.”
and now v3.0 says “To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.”
My question is, and I know its not a simple one, does this mean all inter-vlan communication is banned? Is it possible for any tiny holes between vlans to exist, like through rules in the firewall that defines the vlans?
Thanks again
Peter
It’s not that inter-VLAN communication is banned. It’s that if such communication is allowed, then the systems on those connected VLANs are considered connected systems and therefore are in scope for the assessment. The reason is that they have access to the cardholder data environment (CDE) such that if any of those systems become compromised, they could result in the CDE being compromised.
So this is a sea change from 2.0, where you could have inter-vlan talk as long as it was restricted to the minimum necessary, no?
No. This is not a change. Merely the Council clarifying for everyone what is meant by connected systems. The Open PCI Scoping Toolkit is the best source for understanding the details of connected systems and why they too are in scope for assessment.
Thank you. I guess connected is connected, no matter what port or protocol. The newer wording is more clear on that.
We wanted to put all VLAN’s (internl and DMZ) into one virtual router (VR). Although all VLANs will reside in one VR, only the internal VLANs will have IP forwarding (routing) on. So all DMZ and internal traffic would traverse a 20 Gig trunk but would be separated by VLANs hoping to meet our PCI requirement.
This new design will force all DMZ traffic not in the same VLAN to be routed through the firewall yet all internal traffic would route as normal. How are people handling inter VLAN traffic and is that an issue and what are your thoughts on the design.
As long as the ACLs used to implement your solution operate as you have described, then you should still be PCI compliant.
That said, there are some that would not accept the security risk of the single point of failure in your virtual implementation. That risk is that you are relying on the controls to protect the virtual router, VLANs and ACLs and the device on which it all resides. As networking becomes more and more virtual, the greater the potential of compromising one device and, by default, compromise the entire network versus having to compromise multiple, individual devices (i.e., firewalls, routers, switches, load balancers, etc.). It is that risk you need to assess and then accept or go back and re-architect to reduce the risk to something your organization is more likely to accept.
In our DMZ there are both CDE and NON-CDE VLANs that I receives traffic from internet. Is it “deny all” statement is must in CDE VLAN ACL? If so, how to allow internet traffic?
First, is the cardholder data environment (CDE) DMZs logically or physically segregated from any non-CDE DMZs meaning that there is no communication allowed between the DMZs? I’m assuming from your description that is true, but I have learned the hard way that this is not always the case. If communication is allowed, then the DMZs are not properly segregated and your reference to “non-CDE” is not accurate.
The next thing to clarify is the CDE DMZ. I’m assuming when you use the term ‘CDE’ you are implying that it processes or transmits cardholder data (CHD) such as with an eCommerce solution and that no storage of cardholder data is occurring in this DMZ. If you are storing CHD in this DMZ, you are going to have a problem complying with the PCI DSS as the data is stored in an Internet accessible DMZ.
Finally, assuming that the DMZs are properly segregated let’s move on to the issue of Internet access to the CDE DMZ. You may have any ports open to the Internet as long as you justify why those ports are necessary for conducting business. Typically those ports are only 80 or 443, but there might be others that are needed and that is allowed as long as you justify why they are needed. However, don’t be stupid with what you need such as having FTP, RDP or similar very high risk services available. You will also need to show that you restrict inbound and outbound communications between the DMZ and the Internet as well as with any internal networks.
Thanks! As I am new to PCI these blogs are helpful for me
Good questions and understandable answers, good stuff. Thanks all.
So would you consider a vlan that goes to a seperate mpls VPN and then to the Internet (guest wireless access for example) out of scope as there is no connectivity to cde it is only segmented by a vlan tag, vrf lite and an mpls vpn and hence there is no firewall between this network and cde as there is no connectivity required. I would call it virtually air gapped.
As long as your QSA can prove that the wireless VLAN NEVER comes into contact with the CDE, then it is out of scope.
I would love to see you do a post on the “Redirect” style of online credit card processing. NMI calls it “Transparent Redirect” (and has a newer “3-Step Redirect”), EZIC does this (but doesn’t really have a name for it yet), and Authorizenet just came out with their Direct Post Method.
In your view, what is the impact on the merchant’s PCI burden?
Even within the industry, there is serious confusion about whether this takes merchants out of scope.
We are also going through PCI compliance. The people that are informing us of what needs to be done are not the best and I have learned more from researching on the Internet.
Currently we have customer service reps that take orders over the phone and enter the credit card number’s into the website. Would you think this make these desktop machines “in-scope”? They are telling us to filter all traffic in and out of these desktop VLAN’s, which as you can imagine is rather difficult, see as there are countless desktop services used for AV and Patching among others.
I am eager to know what you think, Thanks.
Yes, your desktop systems are in-scope. Think about where the risk is. If any of those desktop machines are compromised, the data that they enter as well as potentially the data in the Web site is compromised. As a result, you need to protect those desktops and control access to them both physically and logically.
This is one of the biggest issues we run into doing assessments. The organization outsources everything but still does the data entry through a Web interface. While this does potentially shrink the amount of devices in-scope, it does not take you out of scope. The PCI DSS says that anything that processes, stores or transmits cardholder data is in-scope. Your desktops definitely transmit cardholder data, but depending on how the Web applications are built, the desktops could also process and even store cardholder data. We have seen instances where Web applications were inadvertently storing cardholder data due to the use of wrong programming methods, so just because you use the Web, does not get you off the hook.
Regarding desktop PCs being in scope, our QSA told us that this only applies when the person/people who use the desktop have access to more than one card number at a time. For example, if a rep takes an order and enters only the card number they have received as part of the sale and cannot lookup other card numbers, then he and the system used are not in scope. Have you come across this before? I would like to know your thoughts as I’m sure it applies to many people who are defining scope.
Sorry I didn’t make that clear in my post. However, if your desktops are not properly segmented from the cardholder data environment (CDE), then they are in scope and must comply with the PCI DSS. What we see out in the field is call centers that have PCs directly tapping into the CDE with no network segmentation.
Would installing and correctly configuring a persaonl firewall and IPS on the desktop segement them out from rest of the network? Going back to the point steve made below- we have call center desktops that take one credit card number at a time and process them using secure connection to the card processor website and we don’t store any credit card data on our systems -so should these desktops be in-scope?
The desktops are an endpoint and are at risk. Therefore, you need to ensure that these endpoints cannot become the breach point. That said, personal firewalls, IPS AND having them write all of their log data to a centralized log analysis system that monitors them for attempted compromise would be what I would recommend.
So the desktops are still in-scope – regardless of handling one credit card number at a time or having access to more than 1 credit card numbers.
They are still cardholder data entry points and are at risk of compromise. They may only come into contact with PANs one at a time, but over the course of a day, they can enter 100s and that is enough of a target for someone installing a keyboard logger or similar data capture solution. As a result, they need to be protected. This is no different than credit card terminals and integrated POS. Those also have to be protected.
Great – thank you for the confirmation. Also, i have heard this rumor that let say we get the credit card data and let say we permanently delete the card number after it has been processed. Since the card data has been deleted the system is no longer in the scope for PCI DSS. Can you please comment on that?
It’s the “permanent deletion” part that will get you in trouble. Most database management systems like Oracle, DB2, SQL Server, etc. do not really support good permanent deletion capabilities that meet US Department of Defense secure deletion standards (the standard most security professionals hold up as the most secure). As a result, an organization has to develop their own and, depending on the DBMS, that can get tricky. However, until that deletion occurs, the system retains cardholder data, so it still remains in scope for assessment.
I am sort of new to PCI compliance myself, i did attend a seminar in Toronto in June 2010, however i left with more questions than when i entered the room!
Our setup is basically 2 load balancers in front of all servers, all traffic goes through these load balancers that also act as our firewall. All servers behind are NATed via these load balancers. Now our CDE can be accessed only via the internal network, not from outside, IE all web servers talk to DB servers on local LAN subnet, not on public subnet… Is this considered segmented? or should i also create an internal VLAN for the CDE? All servers run iptables and allow only the ports and other servers that need to communicate with each other. How much farther do i need to go to pass PCI compliance with respect to this type of segmentation?
Thanks in advance for any help…
Have a great day!
Hi Rob,
I’m quite worried that you use a load balancer as a firewall on the public edge of your network. And if a public web application has e.g. an SQL Injection vulnerability, then your data in the DB can be pulled out. It’s not just about Network segmentation, you must think security as a whole.
I am a QSA and do not currently personally have a network that I manage. However, you are right that security needs to be thought of holistically, not just in static instances.
Am I inferring correctly that you’d accept network segmentation to consist of separate VLANs with properly documented and restrictive ACLs between them, even without a traditionally-named “firewall” involved? My interpretation (and that of my QSA) has been that a firewall specifically needs to be involved.
If your answer is yes, note that I’m not going to use that as some proof to my own QSA to change their thinking…I’m quite aware that QSAs differ; that’s life! 🙂 I’m just curious about your viewpoint.
First, I was talking about an internal network, not an externally facing network. I always recommend firewalls for anything externally facing.
That said, I guess being a former network administrator, I toss it back to you – what does a firewall provide in addition that ACLs in the switch do not? Properly configured, a switch these days can do all of the alerting that a firewall would provide. The key though in using only ACLs is that you also need to have network monitoring (NIDS/NIPS) turned up aggressively so that you are monitoring both sides of the switch in question and alerting on any spurious traffic. However, that is already a requirement of the PCI DSS.
That said, there will still be situations where stateful packet inspection is needed even internally. In those instances you can either go with the firewall feature set or another interface on your firewall.
Bit of a PCI newb, but I have a question I have researched around a bit and can’t find a straight answer…or responses differ.
Assuming my external firewall passes the PCI external testing am I sufficiently NETWORK SEGMENTING my lan users from my Debit machine? We don’t store cardholder data at all…we only use debit machines. Also, would it be enought to simplay have different subnets for the lan vs debit machine subnet…no VLAN’s in otherwords just subnets?
Greg
Anything that separates, provides controls that limit access in and out of the cardholder data environment (CDE) and that you can monitor provides proper network segmentation.
Separate subnets will provide that as long as there is a firewall or router that has ACLs controlling the flow of users and traffic in and out of the subnet. You also need monitoring from an IDS/IPS or other network monitoring solution so that should anomalous traffic or users be detected, an alert can be generated and investigated. However, just implementing subnets, VLANs or similar solutions without the controls and/or monitoring will not be sufficient.
What do you mean by ACL on a switch ? Unless it’s a layer 3 switch, which makes it a router I don’t see how ACL could be implemented right ?
And that triggers another question, would a CDE VLAN and other VLANs sharing the SAME physical switch be considered enough segmentation providing that traffic between the two is controlled (firewall or router ACL, and IDS) ?
Thanks, your blog is a priceless resource for my PCI project.
Clipper
ACLs can operate at either layer 2 or layer 3 depending on how you define and use them. But you are right, ACLs are typically associated with layer 3 devices which are most typically routers.
VLANs on the same device being segmented depends on the controls between the VLANS and who or what have access between them.