Network Segmentation – One Last Discussion

Based on feedback I am getting, my previous posts regarding network segmentation are still not getting the point across regarding proper network segmentation.  So, this time I am going to use my post regarding the Control Triad and hopefully everyone will now understand what constitutes appropriate network segmentation.

As a quick refresher, the control triad is compromised of preventative controls, detective controls and corrective controls.  All of these control types are required to ensure a secure environment.  The more individual controls you have under each of the three control types, the less likely an incident will occur and the more coverage you should be able to afford your organization should a control go temporarily out of compliance.  However, an individual control can really only appear under one of the control types otherwise that control is diluted as it becomes a single point of failure causing the control triad to not function properly.  With that explanation, let us look at proper network segmentation from the control triad perspective.

Preventative Controls

The following would be considered the minimum preventative controls when talking about network segmentation.

  • Firewall(s) with rules that restrict traffic to a limited number of ports to/from the cardholder data environment.
  • Router(s) with ACLs that restrict traffic to a limited number of ports to/from the cardholder data environment.
  • VLAN(s) with ACLs that restrict traffic to a limited number of ports to/from the cardholder data environment.
  • Private wireless network(s) use a separate VLAN(s) from the cardholder data environment with access controls enforced for any access to the cardholder data environment from wireless.  Private wireless access points are configured with WPA2 using Enterprise authentication and AES 128-bit or greater encryption.
  • Software firewall on server(s) in the cardholder data environment that restricts traffic to a limited number of ports/services to/from the server(s).
  • Restricted administrative access to infrastructure devices in or controlling access to the cardholder data environment.
  • Access controls that restrict administrative and end-user access to applications in the cardholder data environment or that access the cardholder data environment.

Remember, when I say. “limited number of ports to/from” I mean a very limited number of ports.  Yes, there may be instances where you might have 100 ports open to/from your cardholder data environment, but you better have a valid business reason for every one of those 100 ports.  And just so we are all clear, a valid business reason documents the reason why the port needs to be open, the risk presented to the cardholder data environment that the port is open, actions that have been taken to minimize the risks, and management approval of the port being open.  And the business reason for opening a port needs to be more than just “it needs to be open” or “the application will not function unless it is open.”  You need to document why it has to be open so that in the event of a breach you can quickly rule out the ports that might have been the cause based on the type of attack.

When we talk about restricting access, you need to be restricting access.  In small and mid-sized organizations, restricting access might not be feasible.  In those cases, forcing personnel to go to management to gain access is the way to properly provide control.  In large organizations, what we are talking about is restricting access to fewer personnel than everyone that has access to normal production.  The idea is that not everyone in support or business users should have access to the cardholder data environment.  The rule here is the fewer the better but do not make it so few that you create issues.

If you want to go the extra mile, the following controls can further enhance your security.  However, for some organizations, they come at a cost in operational efficiency that is unacceptable.

  • Disable all unused physical jack connections on all infrastructure devices.  Any activation of a jack requires a service ticket and standard management approvals.
  • Disable dynamic host configuration protocol (DHCP) in all retail locations.
  • Public wireless in retail facilities provided by a separate third party and on a separate circuit that connects to the Internet.
  • Required use of encrypted, two-factor authenticated virtual private network (VPN) connections from any wireless network to gain access to any internal network.
  • Access to the cardholder data environment is not allowed for users connecting through any remote access connection.

Detective Controls

The following would be considered the minimum detective controls when talking about network segmentation.

  • Network and host intrusion detection/prevention systems that monitors the aforementioned firewalls, routers, VLANs and servers that are protecting the cardholder data environment and generate alerts to appropriate personnel when an intrusion or incident is detected.
  • Daily analysis of infrastructure device configurations to ensure that only approved configuration changes are made to these devices.
  • Daily monitoring of devices to alert on any foreign devices that are added or when devices are removed from the network.
  • Daily analysis of log data from the preventative controls to find potentially anomalous log entries that indicate a variance in the preventative controls or a potential incident.
  • Change management records for all infrastructure devices, servers and applications in-scope for PCI compliance.

The key here is to generate alerts should any anomalous activity be detected.  But that is the rub.  What is anomalous?  Anomalies are not always the easiest things to identify or define.  As a result, your detective controls may take a while to fine tune.  However, the organizations that do the best job of managing their detective controls organize their anomalies by the PCI DSS requirements they are trying to meet.  This allows them to tweak their anomaly detection capabilities by PCI DSS requirement.

Then there is the issue of what do you do if you detect an anomaly?  Most of the time, an anomaly is not dealt with because of one of two reasons.  The first reason is because the detection solutions are new and are not functioning properly because no one has taken the time to tune them.  The second reason is that because of changes in the environment, the detective controls need to be re-tuned to reflect the changes.  Regardless of why, the detective controls need to be adjusted so that they are not generating excess false positives resulting in people chasing phantom issues.

If you want to go the extra mile, the following controls can further enhance your security.  While these sorts of tools are available as open-source solutions, there are also many commercial solutions as well.  Regardless of whether they are commercial or open-source solutions, tools that will perform these functions typically take a significant amount of time and effort to tune so that they provide the right amount of information for the right incidents.

  • Real-time analysis of infrastructure device configurations to ensure that only approved configuration changes are made to these devices.
  • Real-time monitoring of devices to alert on any foreign devices that are added or when devices are removed from the network.
  • Real-time analysis of log data from the preventative controls to find potentially anomalous log entries that indicate a variance in the preventative controls or potential incident.

All real-time does is provide you with instantaneous alerting.  Most small and even mid-sized merchants do not need real-time analysis and alerting.  Not that they cannot use it, it is likely overkill for their environments given the threat of attack.  However for governmental agencies/departments, financial institutions, health care organizations and most large merchants; real-time analysis and alerting is mandatory.

And if you think tuning for daily reviews was painful, tuning real-time analysis and alerting systems is at least twice as painful.

Corrective Controls

The following would be considered the minimum corrective controls when talking about network segmentation.

  • Change management procedures.
  • Incident response plan(s) for addressing any issues identified by the detective controls.
  • Root Cause Analysis (RCA) procedures.
  • Action plans that result from the incident response process that require changes to the preventative and/or detective controls.  At a minimum, the action plans must document the correction needed, the person(s) responsible for getting the correction completed and the timeframe for the correction to occur.
  • Internal audit review of the preventative and detective controls.
  • QSA review of the preventative and detective controls.

Here is where a lot of organizations miss the boat.  You have detected an anomaly, you dealt with the anomaly, but you do not analyze why the anomaly occurred or you do an analysis but then you do nothing to correct any issues that might have been identified.  As a result, the anomaly continues to be encountered but actions are not taken to minimize or even eliminate occurrences.  This is why the advanced persistent threat (APT) is successful.  APT relies on the fact that eventually all organizations get sloppy and do not take corrective actions to maintain or even improve their controls.

There may be a number of preventative, detective and corrective controls that I may have missed or did not consider since everyone has unique environments.  At a minimum, if your organization has implemented these controls and they are all operating effectively, you are going to better than the majority of organizations out there and much less likely to have a serious incident that could result in a breach.

And that is the problem all organizations face, keeping these controls functioning effectively every day without missing a beat.  That is why we have defense in depth.  If one control is not functioning properly, there are other controls that will cover in the interim until the control is back functioning properly.

Finally, as I always like to remind people, just because you implement all of these recommendations does make you invincible.  All these recommendations do is just making the likelihood of an incident and the potential damage resulting from an incident lower than if you had little or no controls in place.  How much lower depends on a number of factors, but the risk will be lower.  And after all, it is all about lower risk.

Hopefully the issue of what constitutes appropriate network segmentation has now been put to rest.


20 Responses to “Network Segmentation – One Last Discussion”

  1. 1 Alexander Anago
    November 28, 2015 at 3:37 AM

    Good article and inline with what I advise my client, for once I have seen someone that we have same thought about PCI segmentation and more. Just to drop a few points, it is go to classify controls and map it to each of the risks you wish to address.

  2. 2 Simon
    November 20, 2013 at 4:42 PM

    Thank you for the excellent discussions/explanations on PCI. They are much appreciated and demonstrate a deep granular knowledge of the components involved; I’ve especially benefited from the Network discussions.

    Here’s a question that has come up recently for us:
    We have a PCI network ‘zone’ which is a virtualized network on campus. This zone is separated from all other virtual networks through a single ‘choke point’ which is a firewalled boundary with very specific, granular rules in place. Devices in this zone need common services shared by all other end points on campus: DNS, Active Directory, Windows Updates (from WSUS server on campus), NTP, etc.
    Are data flows to these services (to servers which exist outside the PCI network zone, but on campus) considered a ‘necessary business requirement’ and therefor part of regular business operation? More specifically, does allowing these flows to the required network segments bring those servers (DNS, NTP, AD, WSUS) and segments into PCI scope? OR do these services have to be brought inside the PCI zone and isloated from everything else?
    Thanks in advance for any comment you may have on this.

    • 3 thomas
      April 12, 2015 at 8:40 AM

      Any reply to this? I`m facing the similar challenge.

      Thank you.

      • April 12, 2015 at 11:23 AM

        Take a read of the Open PCI Scoping Toolkit for your answers. Also read my posts on scoping for additional thoughts surrounding what is in scope (see my post series references page).

        All supporting systems such as Active Directory, DNS, DHCP, SIEM, etc. are all in-scope if they are providing services to the systems that actually process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD), i.e., those systems that comprise the cardholder data environment (CDE). The ports/services required to open in the firewall to support these services have a valid business purpose.

        Where most organizations go wrong is documenting the ports/services, but then provide no rationale for those ports/services in some bizarre belief that it is intuitively obvious as to what those ports/services are used. While that might be true for FTP (20/21) or DNS (53), that is not necessarily as obvious for Active Directory or SIEM as those vary by version and vendor. It is not uncommon to run into network administrators and security personnel that came into the environment recently and have no idea as to what the ports/services are used for because of the lack of documentation provided by the last network administrators.

  3. 5 Neon
    June 7, 2013 at 9:28 PM

    Does the decrypted traffic going through internet firewall is acceptable for PCI compliance? The internet firewall is under PCI scope and decrypted traffic may contain PAN data.

    • June 10, 2013 at 7:43 AM

      I am assuming from your description that your SSL or VPN endpoint is at your Internet-facing firewall so that the firewall can inspect the traffic. That is acceptable as long as you re-encrypt the traffic for delivery to wherever that traffic is going. Most organizations use SSL from the firewall to the ultimate endpoint.

  4. 7 TD
    March 28, 2012 at 2:11 PM

    I am missing something with the “connected to” rule. Say for example I have all my servers that store, process, or transmit card data segmented behind an internal firewall, implement monitoring, etc, and restrict access to very specific ports and workstation IP’s. I understand completely that the workstations that are authorized via IP and specific ports to access the cde behind the firewall are in scope. However, what about the workstations that are on the same network segment as those workstations that can access the cde. Are they in scope? I understand that these machines that are not authorized to access the cde can be used to breach the machines that can access the cde,because they are “connected to”, however, if I have the control triad in place for the machines that can, do I meet the segmentation requirement.

  5. 8 Paul
    January 23, 2012 at 3:38 PM

    Once I have my network properly segmented, how can I remote access this PCI zone in a secure fashion. For example I have a database/server that holds all of my cardholder data…how can I run patches and security updates without giving this PCI zone access to the internet and also bring my other networks into scope…

    • January 23, 2012 at 9:53 PM

      You patch the old fashioned way of downloading the patches to a machine that has Internet access. Move those patches to a USB thumb drive or CD/DVD and put that in the devices in your cardholder data environment to patch them.

      The other way is to use WSUS, CA Unicenter or similar patching tool to obtain the patches and then stage them for installation into the systems without Internet access.

  6. 10 Ns
    June 14, 2011 at 3:45 PM

    Does anyone have an estimated cost for setting up a new PCI segmented environment? In this process we will only collect the card data on our web servers and passing it onto our 3rd party card processor. We have reached out to QSA and got average of $100,000 per year cost. Is that reasonable?

    • June 14, 2011 at 3:57 PM

      Without very detailed specifics about your proposed cardholder data environment (CDE), I have no idea whether or not $100K is reasonable. However, if you trust the advice your QSA is providing you, then I would tend to believe that they are not pulling your leg. Making such an estimate would go well beyond what the blog is about.

  7. 12 ParrotBob
    March 30, 2011 at 1:28 PM

    So I’ve read through this discussion and have a question:

    I have 10,000 workstations — basically call centers — which access both web and fat clients in the PCI Zone. I understand that my workstations are in scope; but what is the point of creating a network zone if all my switches are still in place and transmitted clear data.

    Am I expected to maintain documentation and appropriate controls on 3,000 switches?

    I can only see two solutions

    1. The switches are part of the card older environment and are required to meet PCI specifications. In which case the zone only gets me control to PCI application servers. HR servers, etc…would be out of scope.


    2. Require all my apps to encrypt all the way to the desktop.

    I am facing political problems in both senarios.

    • March 30, 2011 at 8:25 PM

      Those switches transmit cardholder data, so they are in-scope unless as you point out you get your applications to encrypt their data streams. You could implement Kerberos with session encryption would get your switches out of scope. You could also go to IPv6 for encryption between end points. Unfortunately, for most organizations, Kerberos, IPv6 or application encryption is out of the questions, so this is where you need to get a tool to maintain and enforce a common configuration for all of those switches. With a common configuration and a way to enforce that configuration standard and make sure that any change is flagged, you can then rely on the tool and some sampling to prove the tool works to maintain the common configuration across the network. That way you can be reasonably assured that all devices are consistently configured and maintained that way and therefore also maintain their security.

  8. January 18, 2011 at 6:45 AM

    Excellent article, but one question. In the point form item:

    “VLAN(s) with ACLs that restrict traffic to a limited number of ports to/from the cardholder data environment.”

    Would it also be acceptable to have a router with two subnets that have ACL’s that block ALL traffic between the 2 subnets?

    I have POS locations that don’t store cardholder data but do have debit machines. I was hoping to be OK to put the debit machine on one subnet and the PC/POS system on the other and block all traffic between the two via ACL’s.


    • January 18, 2011 at 4:56 PM

      Usually VLANs with ACLs and routers with ACLs are mutually exclusive in that organizations do one or the other. However there is no reason that they couldn’t do both, but it could result in some “odd” issues with conflicting ACLs. That said, your router with two subnets example meets the bill as well.

  9. 16 Dimitris C.
    January 10, 2011 at 4:05 AM

    This is by far the best “explanation” of what Network Segmentation means from a PCI-DSS perspective, thank you for this great article!

    If you haven’t done so, I suggest you make a book out of your PCI-DSS experiences; together with this Blog, it would be a great tool for all of those who try to justify themselves to Management as well as, understand and go deeper into what PCI-DSS really means/is!

    I really wish there were more like you out there that take “this” seriously the way you do (yes, I’m talking about Auditors, Consultants and Management [not necessarily Senior])!

    • January 10, 2011 at 5:47 PM

      Thank you for the compliment. The key point I wanted to make is that appropriate network segmentation is more than just firewall rules and ACLs. There is much more needed in order to ensure appropriate network segmentation than just restricting ports.

      • 18 Dimitris C.
        January 11, 2011 at 4:27 AM

        Unfortunately most people in the Card (and Financial) Business think of PCI-DSS as a panacea or as a Marketing Tool to attract more Customers, which is sad to say the least.

        Off course, others think of PCI-DSS and/or Logical Security as a “thorn”, but anyway.

        In my opinion, Management (Senior or not), Shareholders and Stakeholders need to understand that they HAVE TO invest in a Security Management System, whose characteristics should be defined by:

        * Proper (efficient & effective) Due-Diligence
        * Proper (efficient & effective), objective and unbiased Risk Assessment & Risk Management
        * Local (where applicable), National and International (where applicable) Laws
        * Security Industry Best Practices
        * Industry Security Requirements

        Anyway, I really love your posts and I hope you keep it up!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

January 2011

%d bloggers like this: