The Impact of Network Configuration Management on Compliance
With a barrage of news headlines about credit card data theft, companies that store card information are scrambling to meet new rules for securing customer payment data. The cost of failure can be quite high, with estimates reaching $400 per customer name, based on hard and soft costs. Hard costs include notification and remediation, while soft costs include loss of reputation, brand equity, and customer goodwill.

While merchants who collect credit card payment information are already aware of the need to protect cardholder data, the efforts of the PCI Security Standards Council (a consortium of Visa International, MasterCard Worldwide, American Express, Discover Financial Services and JCB) increase merchants’ focus. The Payment Card Industry Data Security Standard (PCC DSS) is a set of published guidelines and procedures for securing payment card information. It represents the Council’s best effort to improve cardholder security by defining and enforcing protective and preventative controls concerning the collection, transmittal and storage of credit card information. Unlike other information-related regulations, PCI DSS actually provides considerable prescriptive detail; merchants have a fairly clear roadmap for enhancing security.

Every merchant is affected by and a potential victim of card data loss. The first phase of PCI DSS enforcement will focus on very large organizations known as Level 1 and Level 2 merchants that process the majority of credit card transactions. When these merchants are in compliance with PCI DSS, the next phase will focus attention on the many—millions—of Level 3 and Level 4 merchants. These smaller organizations are often ecommerce sites, restaurants and other organizations that accept payment cards, but for many fewer transactions. This broad set of smaller merchants is realizing that credit card data protection and PCI DSS compliance are not just a problem for the “big guys.” By the middle of this year even the “little guys” will face compliance penalties. These penalties can be severe; enforcement is now backed by fines and escalating transaction fees.

Which Box Are You Checking?
As described above, the PCI DSS differs from other compliance initiatives by the level of detail it provides. The standard is significantly more prescriptive than regulations such as HIPAA and Sarbanes-Oxley in terms of what it requires of organizations that handle credit card information. At the top level, PCI DSS defines six major headings:

• Build and Maintain a Secure Network
• Protect Cardholder Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

In terms of actionable guidance, these points are too broad. Fortunately, the PCI DSS drills down into greater detail regarding requirements in each of these areas. Beneath these six headings are 12 sub-topics that provide significantly more implementation detail. Most vendors who claim to supply PCI solutions will focus on “checking the box” on one or more of these 12 areas. Further digging shows that each of the 12 sections has as many as 15 or 20 sub-sections containing detailed descriptions of the controls required to be compliant. It is therefore critical to dig through marketing claims to determine how much of the PCI DSS each vendor can actually address.

While each of the 12 requirements is important and adds to the protection of cardholder data, the first requirement, PCI DSS Requirement #1, “Install and Maintain a Firewall Configuration to Protect Cardholder Data,” focuses on the necessary condition of a secure network infrastructure. Specifically, this requirement addresses the configuration and management of key networking devices such as firewalls, switches and routers. Compared to the top-level directive, Requirement #1 is more detailed but still not definitive enough to drive specific actions. PCI DSS Requirement #1 outlines requirements in three key areas of implementation: process, policy and technology. Simply put, it is difficult if not impossible to “check the box” at this level. Compliance requires a more detailed analysis of each of these three areas.

How Policy and Process Drive Compliance
To provide IT professionals with more detailed information for ensuring compliance, the PCI DSS provides another layer of definition (1.x.x) for implementing each of these directives. It is this level of definition where PCI DSS Requirement #1 becomes operational and where IT professionals can develop a plan of action. Consider the first few of these definitions:

1.1 Establish firewall configuration standards
1.2 Build a firewall configuration that denies all traffic from “untrusted” networks and hosts, except for protocols necessary for the cardholder data environment
1.3 Build a firewall configuration that restricts connections between publicly accessible servers and any system component storing cardholder data, including any connections from wireless networks
1.4 Prohibit direct public access between external networks and any system component that stores cardholder data (for example, databases, logs, trace files).
1.5 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT).

In total, PCI DSS Requirement #1 has 20 of these specific elements, which map to a set of best practices covering network policy, process and technology.

Earlier we mentioned policy as a key component of PCI DSS Requirement #1. The PCI DSS puts considerable emphasis on policy, since properly written and implemented policies tie together all the elements of the compliance mix, including people and technology. In fact, the five major requirements listed above (1.1 – 1.5) are actually the policy elements for this section. They express the goals for the more detailed process and technology requirements described below this level. These five statements are fixed; no matter how technology changes or staff turns over or the associated processes evolve to reflect this changing environment, these policy directives are the desired compliance outcomes for the network. In essence, the policies embodied in PCI DSS Requirement #1 form the foundation not just for compliance but also for a fundamentally well-run network infrastructure.

After establishing network policies, merchants then develop the associated processes. These range from the approval, testing and implementation of configuration changes to the quarterly review of router and firewall rule sets. The standard also covers exceptions processing, such as any deviations from standard operating procedures (SOPs). An example of such an exception is the introduction of rogue services or protocols to segments of the network that can reach cardholder information.

Network Configuration Management Ties It All Together
Given the complexity of the typical enterprise network, automation via technology offers the only practical path to PCI DSS compliance. Technology includes not only the devices that are the “gatekeepers” for credit card data (firewalls and routers) but also the management layer that integrates and automates the policies, processes and infrastructure deployed for compliance. Even though the DSS headings and titles mention firewalls specifically, this section is not limited to these devices. There is in fact specific language covering router setup and configuration—an important inclusion given the obviously important role that routers play.

In addition to firewall and router management, PCI DSS Requirement #1 provides specific recommendations for managing the overall network infrastructure. The key to compliance at the management layer is a network configuration management system that can automate the required tasks. Here are some practical examples of the day-to-day network management implications of PCI:

• If FTP, IP Finger, or IP source routing are enabled on a core router, this must be automatically detected and those services disabled. (PCI DSS#1.1.7)
• If SNMP community strings are set to ‘public’ or ‘private’ defaults, those settings must be changed to more secure passwords. (PCI DSS#2.1)
• Inbound network traffic must be restricted to IP addresses that are contained within a DMZ (PCI DSS#1.3.1)
• Role-based administration must be employed to ensure that only authorized resources can change or access information on network devices that protect cardholder data. In addition, workflow rules should be set up to ensure that changes to sensitive network devices are approved by higher-level resources within the organization (PCI DSS#1.1.1)

It is possible to focus on the prescriptive rules described above with a set of separate tools. However, without a strong, centralized network management capability, the effort will be staff intensive and add to already burdensome daily network management tasks. Organizations that look to PCI compliance as an opportunity to improve overall IT management via widely applicable best practices will see out-sized returns on their investment. Their network operations will run more efficiently; their infrastructure, assets and data will be better protected; and they will naturally conform to other compliance mandates such as Sarbanes-Oxley and HIPAA.

Added Bonus—Strong Network Management Contributes to Other PCI Requirements
While we have focused on PCI DSS Requirement #1 in this discussion, organizations that install automated network configuration management will pass compliance audits for PCI DSS Requirement #1 as well as experience an additional return on their investment in the form of increased operational efficiency and a more secure and manageable network.

As noted above, PCI DSS Requirement #2 also has network management implications; “Do not use vendor-supplied defaults for system passwords and other security parameters.” This section includes specific requirements to change vendor-supplied default settings for passwords, community string, unnecessary accounts, wireless access keys and superfluous or dangerous services. This section also reinforces the directives in PCI DSS Requirement #1 to establish configuration standards based on recognized standards such as the National Institute for Standards Technology (NIST) or the Center for Internet Security. Finally, PCI DSS Requirement #12 reinforces the underlying role that policies play in protecting cardholder information. It echoes the points throughout the entire PCI standard: “Maintain a Policy for Information Security.”

Industry deadlines, fines, higher fees and the prospect of an escalated threat environment put pressure on all merchant organizations to demonstrate compliance with the PCI Data Security Standard. Too many are attempting to get by with “check-box” compliance, and vendors do not help by making claims about satisfying various parts of the standard. Achieving deep compliance with the spirit and letter of the standard requires an understanding of the component level and solutions targeted at that level. For PCI DSS Requirement #1, a mix of policy, process, products and management form the basis of a solution. Organizations that follow this path will better protect both their cardholder data and their overall business.

Rick Caccia is vice president of Product Marketing and Larry Lunetta is vice president of Strategy and Corporate Development for ArcSight. www.ArcSight.com