Even for those versed in PCI DSS, there are benefits to understanding its origins.  The roles and responsibilities that fall to various parties, as well as the appropriate use of the instruments involved in validating compliance, are intertwined with the origins of the standard.

The Inception

In 1999, Visa introduced its data security program, which was formally named the Cardholder Information Security Program, or CISP.  The program was intended to enhance the protection of cardholder information and detailed twelve areas of focus, known as the digital dozen:

1. Install and maintain a working firewall to protect data.
2. Keep security patches up-to-date.
3. Protect stored data.
4. Encrypt transmission of cardholder and sensitive information across public networks.
5. Use and regularly update anti-virus software or programs.
6. Restrict access to data by business need-to-know.
7. Assign a unique ID to each person with computer access.
8. Do not use vendor-supplied defaults for system passwords and other security
9. Track all access to data by unique ID
10. Regularly test security systems and processes.
11. Maintain a policy that addresses information security for employees and contractors.
12. Restrict physical access to cardholder information.

Upon comparing the twelve requirements of PCI DSS, it is clear that the standard is simply the digital dozen reordered and expounded upon.  Nevertheless, much like “the Dude,” CISP abides.  That is, it is not a defunct compliance initiative: it still exists and still pertains to all Visa transactions.  What has changed is that CISP now references PCI DSS as the standard to which Visa’s member banks must hold their merchant clients.

Implications

That’s an important distinction: PCI DSS does not require adherence of Visa merchants to specific behaviors and standards.  Rather, CISP obligates Visa’s member banks to require their merchants to adhere to the standard.*

Similarly, the security programs governing the transactions of the other card brands now reference PCI DSS, including those maintained by Master Card (the Site Data Protection program or SDP), American Express (the Data Security Operating Policies or DSOP), and Discover (Discover Information Security and Compliance program or DISC).**

Partnering

Visa and Master Card were the first to transition from separate, differently focused standards to a common approach.  That such antagonistic competitors would do so is a testament to the persuasiveness and vision of Bob Russo (currently the General Manager for the PCI Security Standards Council) and an indictment of the state of credit card security at the time.

It is said that Russo, among others, convinced the associations that a unified approach to data security was in their best interest.  As a result, in a move to avoid external regulation and to shore up consumer confidence, version 1.0 of the standard was published in December of 2004 with an original compliance deadline of June 30, 2005.

PCI SSC

At this time, the groundwork was laid for the Payment Card Industry Security Standard Council, LLC.  By handing the standard over to a separate corporate entity, the brands insulated themselves from any appearance of collusion that might have antitrust implications.  When the first update to the standard was published in September of 2006, the council (PCI SSC) officially assumed ownership and maintenance of the PCI DSS and the associated compliance validation instruments (Self Assessment Questionnaires or SAQs).

In the two years since its inception, the PCI SSC has added the PIN Entry Device Standard (PED), the Payment Application Data Security Standard (PA DSS), and the certification programs for compliance assessors and scan vendors to their list of charges.  They have also continued to develop the standard, with version 1.2 due out in the coming months.

The associations payment brands dictate validation requirements through these programs based upon the number of transactions you conduct for their card brand.

*The Payment Application Data Security Standard (PA DSS) goes one step further:  the associations require member banks to require merchants to require vendors to observe PA DSS.

**American Express and Discover are note card associations, and have direct contractual relationships with merchants who process their cards.

”Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.”

In this article, we take a look at what this means for you as a PCI DSS professional.  We begin with an overview of how the Secure Sockets Layer (SSL) works, define an “open, public network” and then explore what you need to do to validate your PCI DSS compliance in this area.

How SSL and TLS Work

The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are similar protocols, both designed to encrypt information in transit over the Internet.  They are extremely similar in functionality and, for the purposes of our discussion, may be considered equivalent.  You can use SSL/TLS to secure almost any type of Internet transmission, but the most common use is to encrypt web communications using the HTTPS protocol.

SSL and TLS communications begin with a handshaking process between the two communicating systems.  The system initiating the connection (in the case of the web, this is the end user) contacts the server and requests an SSL/TLS connection.  With that request, the user’s computer sends a list of encryption algorithms that it can support.  The server then analyzes that list and compares it to its own list of supported algorithms, selecting the most secure algorithm that both systems share in common.   The server then notifies the client of its selection and provides the client with a digital certificate that includes the server’s public key.

The client then verifies the validity of the server’s certificate (ensuring that the server is what it claims to be) and uses the public key contained in the certificate to encrypt a shared session key that it transmits back to the server.  Now that both systems have the same session key, they use it to encrypt all of their communications from that point forward.

What Is An Open, Public Network?

The phrase “open, public network” caused much confusion in the early days of PCI DSS.  Fortunately, the PCI council recently clarified their intent with the following statement:

“Examples of open, public networks that are in scope of the PCI DSS are the Internet, WiFi (IEEE 802.11x), global system for mobile communications (GSM) and general packet radio service (GPRS)”

The bottom line is that you must use SSL or TLS to encrypt communications containing cardholder data that take place over any network that doesn’t belong to your organization.  This includes the Internet, cell phone data networks and any other type of network outside of your control.  It also includes any wireless (WiFi) network, even if it belongs to your organization.

How Do I Implement SSL?

To implement SSL, you need to follow several steps:

1. Obtain an SSL certificate. The cheapest way to do this is to purchase one through the Go Daddy $14.99 SSL Sale!
   
2. Install the certificate on your server.  If you use a web hosting service, chances are that they’ll be able to install this certificate for you.  Otherwise, you’ll need assistance from your technical staff.
3. Disable non-encrypted communications, if desired.  You may wish to continue to allow unencrypted web traffic (standard HTTP) on your server if you have many pages that do not process cardholder data.  If you do this, be sure that you configure the server so that pages that do process credit cards are only available over the HTTPS connection.

When choosing the version of SSL that you wish to implement, it’s critical that you not choose a version earlier than SSL v3.0. The “Navigating PCI DSS: Understanding the Intent of the Requirements” document states:

“Note that SSL versions prior to v3.0 contain documented vulnerabilities, such as buffer overflows, that an attacker can use to gain control of the affected system.”

That’s about all there is to it. SSL and TLS are basic technologies that enable you to secure cardholder data in transit over the Internet. They’re fairly straightforward to configure and their use is clearly mandated by PCI DSS.

• (12.5.1) creating and distributing security policies and procedures
• (12.5.2) monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel
• (12.5.3) (12.9) creating and distributing security incident response and escalation procedures that include:
• (12.9.1) roles, responsibilities, and communication
• (12.9.1) coverage and responses for all critical system components
• (12.9.1) notification, at a minimum, of credit card associations and acquirers
• (12.9.1) strategy for business continuity post compromise
• (12.9.1) reference or inclusion of incident response procedures from card associations
• (12.9.1) analysis of legal requirements for reporting compromises (for example, per California bill 1386)
• (12.9.2) annual testing
• (12.9.3, 12.9.5) designation of personnel to monitor for intrusion detection, intrusion prevention, and file integrity monitoring alerts on a 24/7 basis
• (12.9.4) plans for periodic training
• (12.9.6) a process for evolving the incident response plan according to lessons learned and in response to industry developments
• (12.6; 12.6.1.a) maintaining a formal security awareness program for all employees that provides multiple methods of communicating awareness and educating employees (for example, posters, letters, meetings)
• (10.6.a) review security logs at least daily and follow-up on exceptions

(12.2.a) The Information Technology Office (or equivalent) shall maintain daily administrative and technical operational security procedures that are consistent with the PCI-DSS (for example, user account maintenance procedures, and log review procedures).

System and Application Administrators shall:

• (12.5.2) monitor and analyze security alerts and information and distribute to appropriate personnel
• (12.5.4) administer user accounts and manage authentication
• (12.5.5) monitor and control all access to data
• (12.8.1) maintain a list of service providers
• (12.8.3) ensure there is a process for engaging service providers including proper due diligence prior to engagment
• (12.8.4, 12.4) maintain a program to verify service providers’ PCI-DSS compliant status, with supporting documentation
• (10.7.a ) retain audit logs for at least one year

The Human Resources Office (or equivalent) is responsible for tracking employee participation in the security awareness program, including:

• (12.6.1.b) facilitating participation upon hire and at least annually
• (12.6.2) ensuring that employees acknowledge in writing at least annually that they have read and understand the company’s information security policy
• (12.7) screen potential employees prior to hire to minimize the risk of attacks from internal sources

Internal Audit (or equivalent) is responsible for executing an annual (12.1.2) risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment.

General Counsel (or equivalent) will ensure that for service providers with whom cardholder information is shared:

• (12.8.1, 12.4) written contracts require adherence to PCI-DSS by the service provider
• (12.8.2, 12.4) written contracts include acknowledgement or responsibility for the security of cardholder data by the service provider

(12.3) For critical employee-facing technologies (inclusive of remote access technologies, wireless technologies, removable electronic media, email usage, internet usage, laptops, and personal data/digital assistants), departmental procedures shall require:

• (12.3.1) explicit management approval to use the devices
• (12.3.2) that all device use is authenticated with username and password or other authentication item (for example, token)
• (12.3.3) a list of all devices and personnel authorized to use the devices
• (12.3.4) labeling of devices with owner, contact information, and purpose
• (12.3.8) automatic disconnect of remote access technology sessions after a specific period of inactivity
• (12.3.9) activation of remote access technologies used by vendors only when needed by vendors, with immediate deactivation after use

Departmental usage standards shall include:

• (12.3.5) acceptable uses for the technology
• (12.3.6) acceptable network locations for the technology
• (12.3.7) a list of company-approved products
• (12.3.10) prohibition of the storage of cardholder data onto local hard drives and removable electronic media when accessing such data via remote access technologies
• (12.3.10) prohibition of copy, move, storage and print functions during remote access

• Access rights to privileged User IDs are restricted to least privileges necessary to perform job responsibilities
• Assignment of privileges is based on individual personnel’s job classification and function
• Requirement for an authorization form signed by management that specifies required privileges
• Implementation of an automated access control system

(3.1) Procedures for data retention and disposal must be maintained by each department and must include the following:

• legal, regulatory, and business requirements for data retention, including specific requirements for retention of cardholder data
• provisions for disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data
• coverage for all storage of cardholder data, including database servers, mainframes, transfer directories, and bulk data copy directories used to transfer data between servers, and directories used to
• a programmatic (automatic) process to remove, at least on a quarterly basis, stored cardholder data that exceeds business retention requirements, or, alternatively, an audit process, conducted at least on a quarterly basis, to verify that stored cardholder data does not exceed business retention requirements
• (9.10) destruction of media when it is no longer needed for business or legal reasons as follows:
• cross-cut shred,  incinerate, or pulp hardcopy materials
• purge, degauss, shred, or otherwise destroy electronic media such that data cannot be reconstructed

[If records management is a centralized function, you may choose to offload the above section to a data retention standard and/or procedure, and then reference that procedure in the policy.]

(3.3) Credit card numbers must be masked when displaying cardholder data.  Those with a need to see full credit card numbers must request an exception to this policy using the exception process.

(4.2.b) Unencrypted Primary Account Numbers may not be sent via email

Configuration standards must include:

• (5.2) updating of anti-virus software and definitions
• (6.1.b) provision for installation of all relevant new security patches within one month
• (8.5.8.b) prohibition of group and shared passwords

Note: This sample is meant to demonstrate how the PCI-DSS might be employed directly to generate a policy. It would require significant adaptation to be deployed successfully in an actual card processing environment. Individual requirements from the PCI-DSS are denoted in parentheses. These annotations may be removed, should you choose to adapt this sample policy to make it suitable for your use.

Issue Date: xx/xx/xxxx
Reviewed: xx/xx/xxxx

Policy Statement

(12.1.1) All card processing activities and related technologies must comply with the Payment Card Industry Data Security Standard (PCI-DSS) in its entirety. Card processing activities must be conducted as described herein and in accordance with the standards and procedures listed in the Related Documents section of this Policy. No activity may be conducted nor any technology employed that might obstruct compliance with any portion of the PCI-DSS.

(12.1.3) This policy shall be reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.

Applicability and Availability

This policy applies to all employees: full-time and part-time, temporary and personnel, and contractors and consultants who are “resident” on site. (12.1) Relevant sections of this policy apply to vendors, off-site contractors, and business partners. The most current version of this policy is available (at X URL or through Y office).

Policy Requirements

• Adherence to Standards

• Handling of Cardholder Data

• Access to Cardholder Data

• Critical Employee-facing Technologies

• Roles and Responsibilities

• Related Documents

  • Standards
  • Incident Response Plan
  • Procedures

Getting Started

The best advice regarding policy creation is: don’t over engineer it!  The policy document should be a definitive guide to conduct, but should not include the implementation details (i.e., procedures).  It may make reference to standards, but it should not contain those standards.

In fact, the simplest and most straightforward way to create a policy for PCI-DSS is to extract the policy directly from the PCI-DSS, almost word-for-word.  This alone won’t make you compliant, but it’s a step in the right direction.

For example, requirement 12.7 says to screen potential employees to minimize the risk of attacks from internal sources.  The policy statement should be just that: We shall screen potential employees to minimize the risk of attacks from internal sources.  What screening results are acceptable under which circumstances should be delineated by HR’s Standard for Employee Screening.  How screens are conducted should be detailed in HR’s Procedure for Employee Screening.

Benefits of the Framework

Why go to the trouble of separating the policy statement from the implementation details?

It limits unnecessary debate.

Policy typically is owned at the highest levels of an organization.  Do you really want senior management to discuss what steps 1-4 should be in the account generation process?  If the policy consists almost entirely of elements that directly are required to be present in order to attain compliance, there isn’t much to debate.

It facilitates change.

Perhaps the only thing more difficult than generating policy is changing policy.  If the policy introduces specific standards or procedural elements, it must be changed whenever the standard needs to be updated or whenever the procedure changes.  By deploying a policy made only of PCI-DSS requirements, the policy only needs to change when the requirements change.

It distributes effort appropriately.

In this framework, the departments responsible for executing the policy are responsible for defining the standards and procedures to do so.  Ensuring that those standards and procedures meet the requirements  becomes the responsibility of the central office or internal audit.  Think of what that will mean in terms of comprehension.  Rather than being handed a 200 page policy wherein their requirements are buried, the department is responding to a 2 page document by contributing aligned standards and procedures.  You may still end up with a 200 page manual, but it will be the work of many and well understood by all.

It speeds implementation.

The departments understand their business processes.  A central policy containing standards or procedures may be incompatible with those processes, and could end up needing to be completely reworked and re-approved.

Meanwhile, the business unit may have an alternate, but equally legitimate mechanism that is more appropriate to their area.  They have a better idea of what will promote and what will stymy the appropriate behaviors among their employees.  And some departments may seize PCI-DSS as an excuse to introduce standards and procedures that they were unable to implement previously due internal resistance.

It simplifies review.

Even for a standard as prescriptive as PCI-DSS, the policy document can be kept to two or three pages. This can greatly simplify the policy review process (which likely involves senior management) that PCI-DSS requires annually.

The Sample Policy

• Introduction

• Policy Statement

• Applicability and Availability 

• Adherence to Standards

• Handling of Cardholder Data

• Access to Cardholder Data

• Critical Employee-facing Technologies

• Roles and Responsibilities

• Related Documents

  • Standards
  • Incident Response Plan
  • Procedures

When the standard first came out, the vagueness of this requirement caused quite a bit of confusion among compliance professionals attempting to understand how they’ll be held accountable by their merchant banks.

Hearing this confusion from the industry, the PCI Council recently released an information supplement providing additional information on the penetration testing requirement.  This supplement clarifies requirement 11.3 in a number of important areas.

Technical Requirements

PCI DSS Requirement 11.3 requires that organizations perform annual penetration tests that:

• Evaluate both the network and application layers
• Include both internal and external testing

What’s Included in the penetration test’s scope?

The scope of PCI-required penetration tests includes all systems and networks within the cardholder data environment.  This is where network segmentation is key.  If you’ve followed the advice of PCI DSS experts and narrowly defined the scope of your cardholder data environment, you’re going to be in good shape when it comes time to perform your penetration test.

Who can perform the penetration test?

Contrary to popular belief, you do not need to use a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) to perform your penetration tests.  In fact, you don’t even need to hire someone to perform the tests — it’s perfectly acceptable to use internal resources.  The key is that you must use experienced penetration testers (i.e. someone who has performed penetration tests professionally in the past).  Furthermore, they must be organizationally separate from those individuals managing the cardholder environment.

What’s the bottom line here?  If your information security staff is actively invovled in the management of the cardholder network (e.g. managing the firewall, intrusion detection system, or participating in the design of the architecture), they’re disqualified from performing the penetration tests.  If your organization has an internal audit staff that is qualified and willing to take on the assignment, they’re a great place to turn, as they naturally have the required independence.

How often should penetration tests be performed?

PCI DSS requires that you perform penetration tests on at least an annual basis.  You also must perform tests anytime you make a “significant” change to the environment.  The definition of “significant” is left up to the discretion of the individual interpreting the standard.  For example, it’s a safe bet that adding a user account is not a “significant” change, while adding a new web server would clearly merit penetration testing.  This is still one of the grey areas of PCI DSS and it’s always safe to err on the side of performing additional tests.

Good luck with your penetration tests!