If you’re a QSA or familiar with PCI requirements you know that you can use network segmentation to isolate the Cardholder Data Environment (CDE) from the rest of the network and reduce the scope of PCI. However, what does that really mean? Can I slap in a firewall and call it done? Within the PCI community there is a lot of debate on just what constitutes “adequate network segmentation” in order to reduce the scope of PCI. I’m going to give you my view on things.
Examples from real PCI assessments and penetration tests
There is a real lack of understanding on how to reduce scope outside of the QSA community (even within). In my opinion, the PCI Council has done a poor job educating merchants and service providers on the ins and outs of adequate network segmentation. This should be a focus of the PCI Council in the immediate future. When I go in to conduct a PCI ROC for the first time I always ask the client a couple of questions 1) if they have segmented their network to reduce scope and 2) I ask that they explain their logic on why they believe what they did reduces PCI scope. The answer to my first questions is always YES. The answer to question 2 is a lot of blank stares, “umms” or “I’m not sure, I wasn’t responsible for that.”
My favorite example of PCI segmentation fail:
Some years ago I was conducting a pen test in support of a PCI engagement and the company (a PCI Service Provider) told me that they had a corporate network and a segmented “production environment” behind an internal firewall and that the production network wasn’t part of the PCI Scope. During my pen test I noticed that from the IP address they assigned me (in a normal workstation subnet) I could directly connect to systems in the segmented production environment using Windows Explorer. I asked about this at the end of the engagement, their response was –yes indeed they had a firewall between their two environments but no rules were configuration to limit traffic and no one in the past had asked them to review the rules.
A more common example:
A more common scenario that I see all the time is this. A company has firewalls or routers in place with SOME restrictions limiting connections in/out of the CDE. However, a review of the firewall ruleset shows many systems that are allowed to talk in and out of the PCI environment for various reasons. Most companies can’t justify what make these restrictions adequate or not. So, what is a company to do?
Here is my take on the most important aspect of adequate network segmentation. The whole purpose of segmentation in a PCI compliance context is to reduce the risk of a compromise of systems unrelated to your PCI processes leading to disclosure of protected card data (credit card info). Most companies run their CDE systems on Windows servers and have a single domain (or several with shared trust) to manage authentication. So Active Directory controls authentication to PCI systems within the CDE and all other Windows systems in the environment. In this scenario, even with very limited connections and locked down firewall rules, access has to be granted to domain controllers and other support servers like SSCM over Windows networking ports (e.g., TCP 445) in order for the shared AD authentication to work. Here’s the challenge, a compromise to system outside of the isolated CDE can still easily lead to a direct compromise of cardholder data. Here’s how — A company employee gets phished and their computer or network credentials are compromised giving a hacker access to your corporate, non-CDE network. In theory, since only the CDE has applied strong security controls via the PCI requirements the hacker easily compromises the corporate environment, giving them domain admin access. At that point the hacker simply connects to a domain controller and then connects in to the CDE with admin level access.
How do you fix this? The best approach is to have separate authentication for the CDE that is not tied to non-CDE systems. For Windows systems this usually means one of two things 1) CDE systems need their own AD domain not trusted or tied to corporate AD or 2) PCI systems should use stand-alone authentication. So, if you apply my suggestion, when the hacker compromises the non-CDE corporate environment and gets domain admin access 1) domain controllers and other support systems won’t have authentication ports open between the environment but 2) and most important even a compromise of domain admin credentials won’t grant you access to PCI systems since their won’t be any shared authentication between the environments. You must have a separate set of credentials to access CDE systems. There are other details for adequate network segmentation, and there is no perfect security but for me this is the most important and has the greatest impact on reducing risk.
LBMC Cybersecurity reviews compliance efforts, can test to assure compliance and can help your team develop an action plan to remediate compliance. If you have questions, please contact us. Learn more about our PCI Compliance services.
Content provided by LBMC cybersecurity professional, Stewart Fey.
