Change and Configuration Solutions Aid PCI Auditors

To the casual observer of the Payment Card Industry (PCI) standard, it might seem that the standard deals exclusively with the servers and point-of-sale terminals that house cardholder data. This is an understandable assumption, given the origin and subject matter of the PCI requirements. However, a careful read of the PCI Data Security Standards (DSS) reveals that almost half of the specifications are aimed at the network infrastructure that transmits the cardholder data.

Managers responsible for IT compliance need to understand that credit card companies hold merchants accountable for not only protecting stored consumer data, but also securing the network transport layer and on-going processes to validate compliance. Due to the never-ending amount of network device change and configurations, it is nearly impossible to determine exactly when a device actually becomes non-complaint. PCI auditors are not only on the lookout for non-compliant devices, but also for a well thought-out security process that is currently implemented, tracked and well documented. This is where an automated change and configuration management system can really assist.

The PCI DSS requirements pertain not just to retailers, but to any credit card accepting organization from university book stores to pay-at-the-pump gas stations. Let’s face it, retail payment systems were not designed with security in mind, they were designed to add convenience to consumers’ shopping experiences. However, hackers have caught on to this oversight and are finding new ways to exploit the weakest network links for their profitability — and they are getting really good at it.

Consider several well-published network data breaches over the last few years:

• February 15, 2005 – ChoicePoint – ID thieves accessed 145,000 accounts.
• April 12, 2005 – LexisNexis – 280,000 passwords compromised.
• April 28, 2005 – Wachovia, Bank of America, PNC Financial Services and Commerce Bancorp saw 676,000 accounts compromised by dishonest insiders.
• November 2006 – UCLA – 800,000 current and former student Social Security Numbers stolen by computer hacker.
• July 2005 through January 2007 – TJX – 45.7 million credit and debit card numbers stolen.
• July 3, 2007 Fidelity National Information Services (Jacksonville, FL) 8.5 Million Records lost due to data breach.

To illustrate the depth of this situation, Privacy Rights Clearinghouse has chronicled data security breaches since January 10, 2005, and has estimated that 167,493,672 records containing personal data have been stolen.

Further underscoring the gravity of the situation, notice the amount of records stolen is rapidly increasing every year. Not only does this equate to bad publicity, but it also lends itself to increasing consumer costs. Hence, the quagmire merchants find themselves in: Do I assume status quo will repel hackers – and PCI auditors or, do I make an investment to help ensure a secure network? In the end, protecting consumer data is less costly than dealing with a security breach and precisely why the PCI Council was formed.
The PCI DSS specifies security requirements across many domains, from documentation and physical security to network encryption and software design, all designed to ensure the safe storage, transmission, and use of sensitive cardholder information.

As defined by the PCI Data Security Standard V1.1, “These security requirements apply to all “system components.’ System components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. The cardholder data environment is that part of the network that processes cardholder data or sensitive authentication data.”

This definition has indeed caused some heartburn among merchants, as they refer to these standards as too broad in scope — or too narrow in some instances — to actually comply with. In essence, there are 12 requirements and approximately 178 sub requirements to deal with.

Furthermore, organizations are required by credit card companies to comply with all these security requirements or face stiff penalties. Case-in-point: Under the new penalties issued by VISA last year, acquirers will be fined between $5,000 and $25,000 a month for each Level 1 or Level 2 merchant that is not validated PCI compliant by September 30, 2007, and December. 31, 2007, respectively.

However to add a twist, there is also an interesting cavetto to the all-or-nothing approach PCI mandate, found in Appendix B of the PCI Data Security Standard v1.1 requirements called, Compensating Controls. According to PCI Security Council’s Glossary, “Compensating controls may be considered when an entity cannot meet a requirement as explicitly stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement [3.4] through implementation of other controls.”

Requirement 3.4 deals with the Primary Account Number (PAN), or the payment card number that identifies the issuer and the particular cardholder account. The compensating controls may consist of either a device or combination of devices, applications and controls that meet all of the following conditions:

1. Provide additional segmentation
2. Provide ability to restrict access to cardholder data based on:
1. IP/MAC Address
2. Application Service
3. User Accounts/Groups
4. Data Type
3. Restrict logical access to the database
4. Prevent/detect common application or database attacks

Given all the routine daily tasks that must be performed by the IT personnel, no wonder it’s a seemingly impossible task to interrupt and implement PCI DSS. So it stands to reason why VISA recently reported that only 40% of Level 1 and one-third of Level 2 merchants have validated PCI compliance.

With so much riding on PCI compliance, network managers are increasingly turning to software to automate specific steps in the compliance process. Automation, if done correctly, helps facilitate the planning, management, review and documentation processes as well as assist with creation, implementation and enforcement of a PCI compliant security policy across the entire network infrastructure.

Network change and control helps demonstrate PCI DSS requirements
The PCI Security Council recognizes that network security is not a destination but a process, and that the ability to reliably control the security of the network is dependent upon the establishment of solid change control processes. Network change policies should be clearly documented, easily accessible to users responsible for daily management of the network, and regularly reviewed and approved by management.

Change processes should include validity checks and management approval for all outgoing changes, and change verification and compliance checks after a change has been made. It’s not enough for an auditor to see that a device has been configured correctly, or even that a set of written procedures exists. To verify that an appropriate change control process is in place, the auditor will want to see evidence that the documented process has been followed on a daily basis.

Beyond describing the change control processes that must be in place, PCI also requires the existence of specific network device configurations such as access-lists and strong encryption. Border routers and firewalls should be configured with explicit access-lists allowing communication only across standard ports which serve a valid business purpose.

Network managers must employ regular password rotation and ensure that no device is ever deployed on the network with vendor-supplied default passwords in place. Any network path that facilitates the transmission of cardholder information must be secured with strong encryption or start to face those aforementioned $5,000 to $25,000 fines.

With 12 chapters and more than 170 individual requirements, planning for compliance with the DSS requirements is a challenge. Automating the change control and configuration process eases the burden of the network manager by providing a structured approach to implementation of the DSS. It should offer advice and best practices documentation in the context of the individual DSS requirements, making it easy for managers to determine which steps need to be taken to ensure compliance with the standard.

Change control processes should be documented and stored so that engineers and managers can access the process documentation on a daily basis. An automated, change control solution can facilitate this, providing the network manager with the ability to include the company’s established policies alongside the individual PCI requirements and vendor best practice documentation.

For example, qualified personal should have the means to easily access the current – not static – status, and supporting documentation, of PCI DSS requirements in one consolidated view. This view should contain:

• PCI DSS Requirement Definition
• 2.1 – Always change vendor supply defaults before installing a system on the network.
• Reports and Links
• Credential and Usage Reports
• Communication Mechanism Reports
• Each Compliance Item and Status:
• Default Password
• Cisco Routers
• 3,772 compliant
• 43 non compliant
• Review Comments
• 05/30/07 – Matt Clark, Updated default passwords policy to include PWs from latest IOS.

With easy access to this content, network engineers looking for direction or confirmation will find it easy to access and review the documentation, ensuring higher adherence to the established processes. Network engineers will be more likely to follow the process when it is widely published than if it is stored in a binder on the shelf of the compliance manager. Auditors will request network managers to demonstrate how the processes are distributed to engineers, and the central repository in the PCI compliance solution will meet the requirement.

One of the largest cost savings provided by having a PCI solution based on automated change and compliance control is the assistance in reducing the scope of the audit. Qualified security assessors (QSAs) are required to set the scope of the audit to the devices that protect, hold, or transmit cardholder data. While it’s incumbent upon network engineers to design the network so that it is properly segmented, a PCI solution can assist in proving this segmentation to the auditor. The solution should provide logical containers to manage each network domain, and change and compliance reporting should highlight the association between the PCI-compliant processes and the in-scope devices to the auditor.

In order to keep up with the changing demands of the business, enterprise networks can absorb multiple changes per day. Engineers were once able to accomplish change management with a battery of scripts and FTP servers, but with today’s heterogeneous networks and heavier audit requirements, this method does not scale to meet current challenges. Full change and compliance control cannot be achieved without a high degree of automation, which is perhaps the largest benefit of a PCI compliance solution.

Automated change control will ensure that every change going into the network, whether through the change control application or not, is detected and stored. The PCI compliance solution must not only be aware of every change on the network, but must provide an auditable history (who, what, when, and why for each change) so that auditors can review the history. For example, PCI DSS Requirement #6, Develop and Maintain Secure Systems and Applications, specifically 6.4, Follow change control procedures for all system and software configuration changes. The procedures must include the following:

• Documentation of Impact
• Management Sign-off by Appropriate Parties
• Testing of Operational Functionality
• Back-Out Procedures

The granular access controls and documentation that are inherent to an automated change control solution can enforce this.
Another PCI DSS requirement states that network managers must be able to build structure compliance tests detailed enough to validate individual configuration lines, but can also be aggregated to form comprehensive compliance policies automatically enforced upon change detection. In order to ensure that any lapses in compliance are immediately identified and remediated, network engineers must have flexible reporting and dashboard capabilities available to them, and any PCI compliance solution must provide this in order to be of significant use.

PCI DSS requirement 1.3.1 requires that firewall policies are established that restrict “…inbound Internet traffic to internet protocol (IP) addresses within the DMZ (ingress filters).” In essence, block access between publicly accessible servers and any system component storing cardholder data. Using compliance tests and policies within the automated change control solution, network managers can ensure that the specific access-list lines needed are in place at all times.

Using automated software, network engineers can assemble a dashboard that shows all pending changes, a list of changes in the past 24 hours, any changes flagged as non-compliant by the compliance engine, and a graph illustrating the overall compliance percentage across the network. If compliance violations do appear on the dashboard, the network engineer can immediately drill into details as to which devices failed compliance, what the offending configuration lines are, and who made the change.With automated change control in place, the network engineer can then rollback the access-list on the device and re-run compliance, resting once the dashboard shows “0” compliance failures.

PCI requires that security policies be reviewed no less than on a quarterly basis, and annually auditors will want proof that these reviews have taken place. A PCI compliant change configuration solution provides network managers with the ability to review current procedures and compliance policies in the context of the DSS requirements. Updates to the policies should be recorded in an auditable history, so that auditors can easily verify the ongoing management of the policies and procedures.

The PCI compliant change configuration solution should provide both current state and trending information on compliance to the established policies, so that network managers can make informed decisions about the direction they give the engineering resources. In addition, both sets of reports are useful to the auditor, since they demonstrate that a high level of compliance has been maintained all year, including the time of the audit.

Preparing for a PCI audit can be a costly endeavor, with tier 3 and 4 merchants spending $250,000-$300,000 on audit preparation. Most of this cost is spent trying to analyze PCI requirements and construct meaningful reports for the auditor. Costs can skyrocket when an auditor spends billable time either wading through network details which haven’t properly been summarized, or when prepared reports were deemed inadequate by the auditor, forcing a scramble to locate new information for a wide variety of resources. Any PCI compliant change configuration solution needs to provide a well thought-out and easily accessible hierarchy of reports that can be printed out for any auditor to clearly acknowledge adherence to PCI DSS requirements.

When selecting a PCI compliance solution, network managers should keep the following criteria in mind:

• Automation – The solution must provide a high degree of automation, especially as it pertains to change control and compliance verification.
• Embedded PCI Knowledge – Look for evidence that the vendor has analyzed the PCI specification, and understands what is required to demonstrate to an auditor, showing compliance has been achieved.
• Change Control – The solution must work in a heterogeneous (multi-vendor) environment, must facilitate a structured approval process, and must contain strong audit capabilities.
• Compliance Enforcement – Structured compliance policies must be detailed enough to validate individual configuration attributes, and must provide automated compliance checking of all detected changes. Extra cost-savings can be achieved when the compliance engine supports automated remediation, staging changes for managers who must only review and approve the remediations.
• Reporting and Dashboards – Dashboards should be flexible enough for an engineer to monitor change and compliance information from a single screen. The product should facilitate the audit preparation by providing a structured and well thought-out list of reports for the auditor.

Achieving PCI compliance is not about where your network is today, but about how you can ensure where it will be tomorrow. An automated, PCI compliant change configuration solution can assist in all phases of preparation for PCI, and carries the additional benefit of cost savings through automation.