PCI:

Payment Card Industry PCI, VISA CISP

Build and Maintain a Secure Network

• Requirement 1: Install and maintain a firewall configuration to protect data.
• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Protect Cardholder Data

• Requirement 3: Protect stored data.
• Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks.

Maintain a Vulnerability Management Program

• Requirement 5: Use and regularly update anti-virus software.
• Requirement 6: Develop and maintain secure systems and applications.

Implement Strong Access Control Measures

• Requirement 7: Restrict access to data by business need-to-know.
• Requirement 8: Assign a unique ID to each person with computer access.
• Requirement 9: Restrict physical access to cardholder data.

Regularly Monitor and Test Networks

• Requirement 10: Track and monitor all access to network resources and cardholder data.
• Requirement 11: Regularly test security systems and processes.

Maintain an Information Security Policy

• Requirement 12: Maintain a policy that addresses information security.

Special Notes:

These Payment Card Industry (PCI) Data Security Requirements apply to all Members, merchants, and service providers that store, process or transmit cardholder data. Additionally, these security requirements apply to all “system components” which is defined as any network component, server, or application included in, or connected to, the cardholder data environment. Network components, include, but are not limited to, firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Servers include, but are not limited to, web, database, authentication, DNS, mail, proxy, and NTP. Applications include all purchased and custom applications, including internal and external (web) applications.

Findings and Observations:

A “controls in place” report is required for compliance. If an initial report is issued with open items, the entity should correct all open items, and the assessor should revalidate that the remediation occurred and addressed all requirements. After the revalidation, the assessor should reissue a fully compliant Report of Compliance (ROC) following the engagement guidleines.

Definitions:

For the purpose of the Security Audit Procedures, the following definitions will be used:

• Requirements: The PCI Data Security Standard requirements by which an assessor validates an entity’s compliance.
  

• Compensating Controls: Controls put in place as alternatives to controls defined in the “Requirements” columns. These controls should also be examined by the assessor, and, in the assessors’ opinion, should meet the intention and rigor of the original requirement. Compensating controls should be “above and beyond” other PCI requirements; it is not a compensating control to simply be in compliance with other requirements in this document.
  

• Testing Procedure: Processes to be followed by the assessor to address individual requirements and testing considerations. These testing procedures list detailed controls that the assessor should find in place to support the requirement. Where these detailed controls are not in place exactly as stated, or cannot be put in place due to technical or other constraints, the assessor should examine compensating controls.
  

• In Place: Please provide a brief description of controls found in place, including those controls found to be in place as a result of compensating controls.
  

• Not In Place: Please provide a brief description controls that are not in place. If a requirement is “Not Applicable” (N/A), please explain.
  

• Target Date/Comments: For those controls “Not In Place” include a target date that the entity expects to have controls “In Place.” Any additional notes or comments may be included here as well.
  

Appendix A: PCI DSS Applicability for Hosting Providers

Requirement A.1: Hosting providers protect cardholder data environment.

As referenced in Requirement 12.8, all service providers with access to cardholder data including hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.4 states that hosting providers must protect each entity’s hosted environment and data. Therefore, hosting providers must give special consideration to the following:

A.1: Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, as in A.1.1 through A.1.4:

A.1.1: Ensure that each entity only has access to own cardholder data environment.

A.1.2: Restrict each entity’s access and privileges to own cardholder data environment only.

A.1.3: Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.

A.1.4: Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider. A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.

Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not necessarily guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

Appendix B: Compensating Controls

Compensating Controls – General
Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk. See the PCI DSS Glossary for the full definition of compensating controls.

The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Companies should be aware that a particular compensating control will not be effective in all environments. Each compensating control must be thoroughly evaluated after implementation to ensure effectiveness. The following guidance provides compensating controls when companies are unable to render cardholder data unreadable per requirement 3.4.

Compensating Controls for Requirement 3.4
For companies unable to render cardholder data unreadable (for example, by encryption) due to technical constraints or business limitations, compensating controls may be considered. Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.

Companies that consider compensating controls for rendering cardholder data unreadable must understand the risk to the data posed by maintaining readable cardholder data. Generally, the controls must provide additional protection to mitigate any additional risk posed by maintaining readable cardholder data. The controls considered must be in addition to controls required in the PCI DSS, and must satisfy the “Compensating Controls” definition in the PCI DSS Glossary. 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/abstraction (for example, at the network-layer).

2. Provide ability to restrict access to cardholder data or databases based on the following criteria:

• IP address/Mac address
• Application/service
• User accounts/groups
• Data type (packet filtering)

3. Restrict logical access to the database.

• Control logical access to the database independent of Active Directory or Lightweight Directory Access Protocol (LDAP).
  

4. Prevent/detect common application or database attacks (for example, SQL injection).

---

--Mdpeters 07:50, 26 June 2006 (EDT)