Building a PCI DSS compliant network [1/12]

PCI, or the Payment Card Industry Security Standards Council was created in September 2006 by the major card issuers, such as Visa, MasterCard and AMEX.

The standards, PCI-DSS (Data Security Standard) were developed to ensure that card holder’s data security was always kept to the highest possible standards.

To reduce the scope of assessment for any network that involves credit card data, it is extremely important that as little credit card data as possible is stored – and if that credit card data is actually stored on a network, that as few machines as possible have direct access to that credit card data.

This could be done in many particular ways. For example, any remote machines cannot access credit card information once encrypted. Storing the data on a separate network then that of the public network (read: internet) will ensure that your scope of assessment area.

If possible, never transmit credit card data over a wireless network. Seriously. The second that you add a wireless network into the credit card mix, your PCI assessments become much more complex – and much more expensive. When possible, keep the credit card data over wires. Wires are easy to see and difficult to listen in on.

There are 12 requirements inside the PCI DSS document.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Under this requirement, the person who is assessing your network for PCI DSS compliance is going to look over your entire network that touches any credit card information.

The first thing your assessor is going ask for is all of the firewall and router configurations. He is also going to check and ensure:

  • processes are put into place for testing and approving changes to router and firewall configurations.
  • processes exist for any new connections inside the network
  • there are valid network diagrams.
    • Must document all connections to cardholder data
    • Must document the flow of CC Data
  • the network diagrams that exist are up to date and valid.
  • the current network diagram is consistent with the firewall configuration standards.
  • that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.
  • that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.
  • that any insecure services, ports and protocols are necessary (ie, HTTP, FTP).
    • Yes. It’s true. You can’t run HTTP unless you have a reason for running it! If it’s not HTTPS it should not be on your credit card data network!
    • that firewall and router configuration standards require review of firewall and router rule sets at least every six months.
      • The assessor will actually check and ensure that reviews of the firewall and router rules have been performed. Ensure that you can leave a paper trail.The way that I recommend doing this is by storing the router and firewall configurations on a Mercurial repository, then allow the person who is assessing the configurations to actually sign the fact that they have verified the configuration by tagging the config and then allowing the reviewer to commit and check in the configuration file to the (private) Mercurial repository.
  • that connections are restricted between untrusted networks and system components in the cardholder data environment, as follows:
    • that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented.
      • updates to operating system and applications should not be done on the public network, especially for anything that handles any credit card data. This means having copies of the update repositories for Windows (WSUS) and Linux (rsync? etc) inside the local CC transaction network.Machines handling credit card processing should only talk to the Internet through secure protocols (SSH, HTTPS), and the internet should not talk to the machines!
  • all other inbound and outbound traffic is specifically denied, for example by using an explicit “deny all” or an implicit deny after allow statement.
  • router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.
  • a DMZ is implemented to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment and that inbound Internet traffic is limited to IP addresses within the DMZ.
  • there is no direct route inbound or outbound for traffic between the Internet and the cardholder data environment
  • internal addresses cannot pass from the Internet into the DMZ
  • the database is on an internal network zone, segregated from the DMZ.
  • the firewall performs stateful inspection (dynamic packet filtering)
    • run a port scanner on all TCP ports with “syn reset” or ”syn ack” bits set—a response means packets are allowed through even if they are not part of a previously established session
    • only established connections should be allowed in, and only if they are associated with a previously established session

Another post will be uploaded tomorrow explaining some of the details that you should include in your Network Diagram, plus some tips for ensuring all of the requirements in the first section are covered.

One Comment “Building a PCI DSS compliant network [1/12]”

  • Tim Post

    says:

    This is a really good start to a comprehensive breakdown of real world compliance. I’m about to do the same thing regarding HIPAA/HITECH, which more often than not requires PCI DSS compliance as well (medical records often contain front/back copies of credit cards used for settling co-payments).

    Looking forward to issue #2

Leave a Comment

Your email address will not be published. Required fields are marked *