Requirement 1.1 of the PCI Data Security Standard (DSS) guides you through the process of configuring and maintaining your firewalls and routers. There is no real science to deciding on what type of device and configuration to use, just some forethought. PCI requirements make it easy for you by telling you what type of firewall to use, how it must be configured, how to maintain it, and what to protect against.

PCI DSS doesn't waste any time getting into change management. Requirement 1.1.1 details a formal process for approving and testing all external network connections and changes to the firewall configuration. There are a couple of things going on here. First, all external connections must be approved and tested. Approval implies that management, or relevant delegates, must know and agree to the connection. Once the connection is made, it must be tested. Testing can range from full on penetration testing to simple port scans to verify that the connection is opened as designed. If this is your first time through PCI DSS, the firewall should be baselined (as a best practice), and any changes to the configuration thereafter must be approved. Each stakeholder should have a say in whether or not the changes actually get implemented.

It's much easier to understand what needs to be secured if you can see it on paper. Requirement 1.1.2 needs a current network diagram. All connections to the cardholder data should be clearly documented, including any wireless networks. This diagram needs to remain current at all times. With a good change management process, keeping the network diagram up-to-date is a simple task.

The flow of data throughout the enterprise is often forgotten when putting together an accurate diagram. In fact, network diagrams in general are poor canvases for graphically depicting the flow of data. Most diagrams are created in Visio^® or a similar tool. Although the tools are quite powerful in what they can do, most engineers think in different ways, thus creating different looking diagrams that may represent the same underlying theme. A method for creating data flows published in an article entitled Data Flows Made Easy illustrates a way you can simplify this process (www.brandenwilliams.com/brwpubs/DataFlowsMadeEasy.pdf). These flow matrices are useful to Qualified Security Assessors (QSAs) and are much easier to maintain than graphical depictions of the same thing.

Requirements 1.1.5 to 1.1.7 were combined, simplified, and expanded in scope in PCI DSS v1.2. All ports and services allowed through the firewall must now be documented – secure or not – and insecure protocols must have additional documentation about their use, business justification, and potentially a risk assessment performed against them in the environment. Requirement 1.1.4 may also be of use here. The administrator needs accurate documentation of all groups, roles, and responsibilities for logical management of network components. This is especially helpful when implementing the rule sets.

Now that you have all your Internet connections documented and your network and data flows clearly defined, Requirement 1.1.3 states that firewalls need to be implemented at each connection point and between any De-Militarized Zone (DMZ) and the internal network. Finally, Requirement 1.1.8 is less stringent in PCI DSS v1.2 firewall, and router rule sets must be reviewed every 6 months instead of quarterly. Be sure to take your review process seriously. Going through the motions on any of the periodic PCI DSS maintenance tasks will quickly land you in autopilot on track for a breach. Your engineers should scrutinize every rule and ensure it needs to be there. One good way to check a rule's use is to log it. If you find rules that are listed in your policy but never actually hit during a 6-month period, chances are the rule is out of date and should be removed.

Confidentiality, integrity, and availability of cardholder data are at the heart of Requirement 1.2. Your firewall configuration has to accomplish several things. The rule of thumb here is to deny nearly all traffic. Only the minimum traffic required to conduct business should be allowed through the firewall – both inbound and outbound. It is much easier to filter everything initially and only open the required ports and protocols on those ports. This is where a good network diagram with data flows, coupled with an accurate list of required services, ports, and protocols (with business justification), is worth its weight in gold.

Denying all traffic from “untrusted” networks and hosts is easy to accomplish. Many firewall solutions do this right out of the box. If not, there is usually a rule that can be configured to do this. It all boils down to failing safe. After processing all the traffic permitting rules in the firewall policy, all firewalls should deny everything else. For example, a common deny-all rule is called the “stealth rule,” whereby all traffic, inbound or outbound, specifically targeting the firewall device itself is dropped. Before that rule goes into play, you must have a rule that allows an administrator to access the management function of the firewall to make changes.

With the traffic being denied for all inbound and outbound traffic, specific rules need to be applied to enable your business to function. Verify the business need against your list of ports, protocols, and services first. To add even more security, if the source of traffic can be narrowed down to specific networks or hosts, make your rule more specific and only allow those through.

Requirement 1.3 in the DSS gets pretty granular with restricting connections between publicly accessible servers and any system component in scope for PCI. What does this mean to you? The database containing cardholder data cannot be in a DMZ that is publicly accessible. Stateful inspection firewalls must be used. If traffic is not explicitly allowed in the rule set, it should be denied. Any Request For Comment (RFC) 1918 addresses are not allowed from the Internet, and Internet Protocol (IP) Masquerading should be used where appropriate with Network Address Translation (NAT) or Port Address Translation (PAT).

RFC 1918, originally submitted in February 1996, addresses two major challenges with the Internet. One is the concern within the Internet community that all the globally unique address space (routable IP addresses) will be exhausted. Additionally, routing overhead could grow beyond the capabilities of the ISPs because of the sheer numbers of small blocks announced to core Internet routers. The term “private network” is a network that uses the RFC 1918 IP address space. Companies can allocate addresses from this address space for their internal systems. This alleviates the need for assigning a globally routable IP address for every computer, printer, and other device that an organization uses, and this provides an easy way for these devices to remain sheltered from the Internet.

Requirement 1.3.8 dictates preventing RFC 1918 address space from accessing DMZ or internal network addresses. Some devices call this “Anti-Spoofing” technology, mainly because an old trick to get around firewalls is to spoof internal IP addresses from external hosts. RFC 1918 addresses originating from the external port trying to come in to the DMZ or internal network should raise a red flag in the logs for the device. The firewall rule set should only allow valid Internet traffic access to the DMZ. Requirements 1.3.2 to 1.3.3 add more color on restricting traffic from the Internet to only those addresses that are in the DMZ and restricting direct inbound routes from untrusted networks into the cardholder environment. Why can't Internet traffic pass to the internal network? Because Requirement 1.3.7 requires the in-scope database to be on the internal network segregated from the DMZ. The cardholder database should never be able to connect directly to the Internet. Front-end servers or services should only be accessible by the public. These servers and services access the database and return the required information on behalf of the requester just like a proxy. This prevents direct access to the database.

Finally, rounding out Requirement 1, Requirement 1.4 mandates personal firewall software on devices that are used to access the organization's network. The devices in question can be employee-owned (maybe a home PC with a VPN Client on it), mobile (such as a laptop or Wi-Fi phone), or both. The firewall must be present on the device, must be active, and cannot be disabled by the user. The built-in Windows Firewall can be used, provided that an appropriate group policy removes the capability to disable it.

PCI DSS v1.2 added more granularity to the requirements around routers, specifically taking Requirements 1.1–1.3 and extending them to routers. The one requirement that seemed specifically targeted at Cisco routers and firewalls has been enhanced is Requirement 1.2.2, even though it specifically only mentions routers. If any network device in scope for PCI has the capability to have a different running and startup configuration, this requirement applies and you need something to check to make sure they are actually in sync. No changes should be made to the running configuration without first going through the appropriate change management procedures.

Additional firewall considerations should be taken with regard to wireless networks and mobile or personal computers. Systems with cardholder information must be segregated from wireless networks for Requirement 1.2.3, and those firewall rules limited only to what is necessary for business. Chapter 7, “Using Wireless Networking,” has more information for you on how to get your wired and wireless networks working securely. These units may not always get critical patches in a timely manner, and the personal firewall provides some assurance.

Requirement 11.4, although not grouped in with Requirements 1 or 2, is part of building and maintaining a secure network.

IDSs detect unwanted activity on networks and systems, mainly from the Internet, but increasingly on hosts (host-based intrusion detection) and Wi-Fi networks (wireless intrusion detection). This activity is usually the product of a hacker executing an attack. IDS can detect malicious activity not normally prevented by firewalls including Trojan horses, worms, viruses, attacks against vulnerable services, unauthorized logins, escalation of privileges, and attacks on applications.

There are many types of intrusion detection or prevention systems that can be used to satisfy this requirement. This is an example of a requirement that companies can leverage to build solid intelligence around their network and produce real-time threat analysis data that can be exported to various risk management software. Below, you will find many types of IDSs that could be used to demonstrate compliance with PCI DSS. For those that you are unfamiliar with, try a couple of Internet searches for more information.

Again, PCI DSS does not dictate which solution should be used. In many cases, this may come down to cost – cost to purchase and cost to maintain. Both the IDS and IPS have their advantages and disadvantages and should be weighed accordingly.

A lot of thought goes into securing a network. You have to think not only about the network devices (e.g., routers, firewalls, IDS) but also about system defaults, configuration management, and encrypting nonconsole administrative access, to name a few.

All organizations should adopt a baseline that is considered to be a minimally acceptable configuration for all systems. It is a key element of security and aids a security team's efforts in reducing the vulnerabilities on their systems from the minute they are deployed, and this reduces the overall security risk to the organization. Requirement 2.2 mandates that all known security weaknesses are addressed and are consistent with industry-accepted system hardening standards. If a particular vulnerability is not addressed with specific hardening techniques, workaround solutions may need to be applied to mitigate the risk. Once you have adopted a standard, the systems should be baselined to ensure all systems are built and hardened the same every time. Creating security baselines on computers and your networks is no trivial task. It takes time and effort, but the end result is priceless. A security baseline is a standard set of security settings that are established for each type of computer or network component in your organization. The baseline configuration is a “point-in-time” configuration and should be updated regularly as new settings are applied. Your organization's security policy should drive what security features are applied to your systems. A well-defined security policy lays the foundation for security elements that must be put in place.

Requirement 2.2.1 mandates that critical servers provide a single service (e.g., Domain name system (DNS), database, e-mail, Web) to the organization. All too often, organizations try to save money by hosting multiple services on the same host. Each service brings its own vulnerabilities and risks to the table and provides a hacker with multiple choices for attack. If too many services are provided by a single server, an exploited vulnerability on one service (i.e., DNS) can bring down or cause a denial of service to the entire server. The integrity of all the services and data is questionable at that point. As a rule of thumb, increasing the number of services provided by a single host degrades the overall security of the server and the organization.

This particular requirement is hotly debated among virtualization enthusiasts as well as small businesses with limited resources and multifunction servers. The use of virtualization in conjunction with this requirement is perfectly acceptable for PCI DSS. The main trick is to remember the host operating system (or the hypervisor if you are running a minimalist host installation) is in scope for PCI, but guest operating systems (or virtual machines) can be scoped out, depending on what they have access to and what they are doing. Remember, any guest host that can see into another guest host with PCI data in it may be deemed in scope.

The other side of this is multifunction servers for small businesses. This is a gray area without a ton of guidance. Depending on how you want to read the literal language, you could read it as broadly as a server with multiple services on it serving a single function; thus, it is compliant with the requirement. If you wanted to overdo it on the narrow side, then every server type service should have its own hardware or virtual machine to run on. The true answer is somewhere in between. Black box solutions are typically viewed as compliant with this requirement, where homegrown ones may not be.

The answer here is to use common sense. You probably don't need to have your cardholder database on a machine that also acts as your Primary Domain Controller and external e-mail server.

You might think this is a “no-brainer,” but not all system administrators know exactly which services are enabled and disabled on their systems and how the system itself is secured. Requirements 2.2.2 to 2.2.4 describe how system administrators must handle the services that are available and running on their servers. Requirement 2.2.2 is standard system hardening whereby all unneeded services are removed, which couples nicely with Requirement 2.2.4 that mandates the same for removing unnecessary scripts, drivers, features, etc. Any service, piece of software, and operating system feature that does not have business justification for running must be disabled or removed.

Requirement 2.2.3 mandates the configuration of all system security parameters to prevent misuse. This particular control includes both a question and answer session with the system and security administrators as well as verification that common security parameter settings are included in the standard configuration. This can be accomplished by reviewing internal vulnerability scan data, as well as interacting directly with the machines. You can expect your assessor to ask things such as “What is your security knowledge?”, “How would you verify secure configurations on your particular equipment?”, and “What kinds of services would you disable immediately after installing a new server?”

System and network administrators, by design, have access to everything. They “own” the network and are responsible for keeping it functioning. However, some of the tools they use are a little less than secure. Many of the tools are antiquated and actually pass user IDs and passwords in the clear (such as Telnet and Rlogin). To accommodate Requirement 2.3, encryption solutions must be used for all nonconsole administrative access. Most modern platforms have open-source solutions for this such as OpenSSH as a replacement for Telnet and “R-Services” (see www.openssh.org for more information). Mainframes will usually require licensed software to enable encryption, so other compensating controls may be considered here.

PCI compliance goes further than just the commercial entity providing the goods and services. Far too often your favorite store is nothing more than a “store front” with no back office, just a building or a Web site that pushes goods. Typically, Web site hosting for these operations is done through a service provider. Requirement 2.4 mandates that hosting providers protect each entity's hosted environment and their data.

Firewall policies tend to forget that outbound traffic should not get a free pass. For firewalls to comply with PCI DSS (and be effective security devices), they must only permit traffic that is necessary for business – both inbound and outbound. To successfully enhance your firewall policies without interrupting your business, consider adding new rules to your firewall that “permit” certain types of traffic and then log any hits to those rules. This will allows you to quickly determine which rules will work and which ones will not.

Without fail, documentation is one of the most tedious aspects of attaining and maintaining PCI compliance. Before your assessor comes on-site, make sure that all in-scope firewall rules are documented and have all the necessary approvals. The expanded scope of Requirement 1.1.5 now requires that all ports and services allowed in and out must have documentation associated with them. Consider performing a risk assessment on those rules and including that documentation as well.

Good internal vulnerability scanning finds most instances of default passwords or configuration on in-scope systems. Many breaches that happen today start with a default or blank password or default to an insecure configuration. Ensure that a vulnerability management program correctly identifies these mistakes and that the management process designed to take findings through to resolution (including the all-important feedback loop!) correctly reports progress on remediation activities.

Before PCI, the notion of a firewall anywhere except for the border of a network didn't exist. In fact, wasn't the old joke about security “Hey, I'm all about security! I have a firewall!”?

Unfortunately for most companies, big or small, rapid growth and pressure to meet financial expectations have stifled security such that compliance initiatives like PCI become challenging. In nearly every company, network segmentation had to be addressed at some level.

Joe's Jumping Jerky Joint, a small company given to Todd by his father Joe 10 years ago, has four stores and an e-commerce Web site that accepts credit cards for payment. Todd was notified by one of his acquirers that he is now a Level 3 merchant and must submit a SAQ to demonstrate his compliance with the PCI DSS. As a former Level 4 merchant, his knowledge of PCI DSS was limited; thus, his stores or online site have not been validated against the controls.

The physical stores use IP-based Point of Sale (POS) terminals that he purchased off of eBay, and they share infrastructure with some nonpayment related machines. There are two PCs that are used by the manager and assistant manager of each store to browse the Web, check e-mail, and access the order fulfillment screens from the online store. There is also one kiosk in the store that allows customers to sign up for e-mail updates. The stores also have a small cafe and tasting area where you can sample some of the jerky and have a light lunch or coffee. Todd provides free Wi-Fi to customers who come to the cafe.

Each store connects to the Internet via a business class Digital Subscriber Line (DSL) for his Internet service, allowing Todd to ensure certain minimum levels of bandwidth and favorable pricing when bundling other services. The business class DSL came with an upgraded router that provides the capability to create a DMZ, but he has not used this functionality to date.

Todd knows that the PCs and the kiosk are not fully up to date with PCI standards and that the wireless network is a problem for PCI, as there is currently no segmentation between it and the wired infrastructure. In order to meet PCI DSS, some changes must be made. Todd does not want to invest thousands of dollars into added infrastructure to comply with PCI DSS. What options are out there?

Luckily for Todd, he upgraded to the business class DSL! The DMZ functionality on the device allows Todd to segment the POS devices onto their own network with relative ease. He needs to purchase a small managed Ethernet switch to accommodate the few POS devices per store. Finally, he needs to review the configuration of his DSL router to ensure that the firewall settings are done appropriately according to PCI DSS. He will not be able to access the POS devices or the POS controller (if applicable) from the PCs on the network, so he may have to adjust some process to go to those machines directly for end of day batch processing.

For the Web site, Todd must work with his hosting facility to ensure that they are providing a PCI compliant solution. He should either ask for their completed Appendix A for his environment (too meet PCI Requirement 2.4 if applicable) or see by checking if they are on the CISP Compliant Service Provider list (www.visa.com/cisp). Regardless, his contract with his hosting company should comply with Requirement 12.8. See Chapter 6, “Protecting Cardholder Data,” for more information. If they are a compliant hosting facility or service provider, he knows he can provide documentation to satisfy his internal assessment requirements for demonstrating compliance to PCI DSS. If not, he must work with them to ensure they take the appropriate steps to become compliant. If he decided to in source his Web site, he would need to document all his firewall rules and make sure he had sufficient ingress and egress filtering. Oftentimes, firewalls will default to a minimal inbound ruleset without restricting outbound traffic at all.

For examples of what Todd's network looked like before and after segmentation, refer to Fig. 12.1 and Fig. 12.2, “The Art of the Compensating Control.”

Flat networks don't only appear at small retailers' store locations, they appear in the corporate offices too – oftentimes with much higher remediation costs.

Consider the case of Christine's Car Commissary, a large retailer with 2000 stores. Christine's company has recently become a Level 1 merchant and is facing fines of $25,000 per month under the VISA Compliance Acceleration Program. She hired a QSA, and among other findings, she discovers that her internal assessors have underestimated the scope of PCI due to their flat corporate network. The store locations have large enough IT installations to make segmentation as easy (if not easier) as James's Jumping Jerky Joint. Instead, she is faced with massive costs associated with upgrading legacy systems not involved in card processing on her corporate network, and many of which are no longer maintained and cannot meet PCI DSS.

Christine knows that she needs to get as many systems out of scope as possible to keep her remediation costs under control. Two years ago, Christine had to upgrade several of the core switches that run her corporate infrastructure simply due to capacity limitations. She smartly purchased for growth and has both CPU cycles and bandwidth to spare. Her IT staff have several VLANs defined in the core switching infrastructure, and with the recent upgrades, they have the ability to place ACLs on some of the switching interfaces (or in some cases, directly on VLANs).

Christine must quickly deploy ACLs to isolate the cardholder environment such that her legacy computing systems are not included in the scope of the assessment. After consulting with her vendors and IT staff, she decides to take a two-prong approach. Several of her distribution switches have empty slots available. She will purchase firewall blades to boost the security and efficiency of her switching network, allowing her to accomplish several things.

Christine is able to focus her IT and Security staff on the above five items, saving both time and money and successfully passes her PCI assessment by concentrating her resources on the in-scope sections of her network.