Manage Learn to apply best practices and optimize your operations.

PCI DSS requirement: Building and maintaining a secure network

The first PCI focus area requires a set of documented configuration standards, perimeter and endpoint protection.

PCI for the Midmarket
How to achieve PCI DSS compliance in a midmarket business: Learn about PCI DSS compliance for a midmarket business, including the standard's six areas of focus and how to document your organization's compliance.
When filling out the PCI DSS questionnaire, is it important to provide documentation?: Gather appropriate documentation as part of security operations.

We begin our in-depth series examining the Payment Card Industry Data Security Standard's six areas of focus and how midmarket IT organizations may best tackle and comply with the standard. In this part, we explore the first major requirement: building and maintaining a secure network.

This section of PCI contains provisions regarding firewall configurations, default passwords and use of encrypted administrative connections. While this information will help you get off to a good start, remember there is no substitute for an in-depth reading of the entire standard.

PCI DSS security standard requirements

PCI requires that you follow a set of documented standards when configuring security and networking devices used in your card processing activities. Specifically, you'll need to create standards that:

  • Specify parameters for firewall-based perimeter protection and include process. descriptions and a network diagram.
  • Require a firewall at every Internet connection and isolating every DMZ.
  • Dictate the use of a formal process for managing firewall rule-base changes, including the documentation of business justifications for each rule.
  • Mandate semiannual firewall rule-base reviews.

Creating these firewall and network device standards is only the beginning of your exercise. You'll also need to create standards for all other system components that require your technical staff follow practices such as:

  • Implementing a single function per server.
  • Disabling unnecessary and insecure services, protocols and functions.
  • Configure security parameters according to business requirements and best practices.

Fortunately, there are a number of resources available to you to get head-start when creating your security standards. I recommend that you first review the standards produced by organizations such as the Center for Internet Security, National Institute of Standards and Technology, and the SANS Institute.

In many cases, you'll be able to simply adopt those standards in their present form or modify them slightly to suit your environment. Once you've created your standards, be sure to store them in an accessible location and communicate them to the members of your technical staff responsible for implementing them. It's not uncommon for PCI DSS auditors to interview system administrators to ensure your standards are properly communicated and not just a paper exercise to satisfy the requirement.


You've no doubt heard by now that it's essential to change any vendor-supplied default passwords or accounts before using a system. PCI DSS documents this best practice and requires you change and/or remove such defaults before connecting a device to the network.

Additionally, you must take steps to secure administrative connections to all system components that take place using any remote access capabilities. You can meet this requirement by adopting industry standard security protocols, such as SSH for obtaining shell access and HTTPS for protecting Web-based administrative consoles.


PCI DSS mandates the use of stateful inspection firewalls to protect your network perimeter from Internet-based attacks and also to isolate your DMZ from the internal network. You must use these devices to prevent direct access to your card processing environment from the Internet, and similarly protect against card processing systems directly accessing the Internet. Another oft-overlooked requirement in this section mandates the use of RFC 1918 private addresses on your internal network.

Judicious use of firewalls can also lend tremendous benefit to your compliance efforts. Properly placed, firewalls can segment your card processing activities into an isolated effort, reducing the scope of your enterprise that must comply with PCI DSS. For more on this approach, read Network isolation as a PCI DSS compliance strategy.


Security best practice dictates the use of software firewalls on all of your endpoint computing devices. You're probably already making use of this technology to protect your systems from threats on potentially hostile networks, but did you know that PCI DSS actually requires their use in certain cases? Specifically, the standard requires the use of personal firewall software on mobile and/or employee-owned devices that are used to access your network and also have direct connectivity to the Internet.

In practice, the most difficult part of this requirement is securing the employee-owned systems used to access your network because these devices are normally outside of your administrative control.

The first strategy you should use here is minimization: Either prohibit or severely restrict the use of personally owned devices to connect to the card processing network. This is the strategy I've seen successfully used in several enterprises. If you absolutely must allow the use of employee-owned devices, ensure that employees agree (in writing) to follow the organization's configuration standards and understand that severe consequences await them if they fail to comply.

Overall, PCI DSS offers a set of comprehensive best practices for building and maintaining a secure network. Chances are good that you're already implementing many of these principles in your enterprise, but you should definitely perform an in-depth assessment to confirm you're meeting the spirit and intent of the standard in your card processing operations.

Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a contributor to, a technical editor for Information Security magazine and the author of several information security titles, including the "CISSP Prep Guide" and "Information Security Illuminated."

Send comments on this technical tip to

Dig Deeper on Audit and compliance planning

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.