Payment Card Industry (PCI) Data Security Standard

Introduction
The Payment Card Industry, especially every company involved in storing, processing or transmitting cardholder data, must maintain processes and infrastructure according to a security standard, defined by the PCI Security Standards Council.

This article is based on the document “Payment Card Industry (PCI) Date Security Standard – Requirements and Security Assessment Procedures”. At the time of this writing, the most current version of the PCI Data Security Standard was 2.0, October 2010.

Inside this article, I use the term “PCI DSS” to refer to the standard. This abbreviation is also used inside the standard documents.

PCI DSS Applicability Information
PCI DSS applies wherever account data is stored, processed or transmitted. The term “account data” is further divided into “Cardholder data” and “Sensitive Authentication Data”:

Cardholder data includes:

  • Primary Account Number (PAN)
  • Cardholder Name
  • Expiration Date
  • Service Code
Sensitive Authentication Data Includes:

  • Full magnetic stripe data or equivalent on a chip
  • CAV2/CVC2/CVV2/CID
  • PINs/PIN blocks

The Primary Account Number (PAN) is the number printed on your credit or debit card. Typically, it has a length of 16 digits. For more information about PANs visit [2].

Note: The PAN is the defining factor in the applicability of PCI DSS. PCI DSS requirements are applicable if a PAN is stored, processed or transmitted.

Scope of Assessment
The PCI DSS security requirements apply to all system components that are included or connected to the cardholder data environment. The term “system components” includes network components, applications and virtualization components.

Note: Virtualization components include virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops and hypervisors.

The scope of the assessment can be reduced by applying proper network segmentation, to isolate the cardholder data environment from the rest of the network. This is a recommendation by the PCI DSS standard and in fact, this may reduce:

  • The scope of the PCI DSS assessment
  • The cost of the PCI DSS assessment
  • The cost and difficulty of implementing and maintaining PCI DSS controls

Note: Without adequate network segmentation, the entire network is in scope of the PCI DSS assessment.

If your cardholder data environment makes use of wireless technology to store, process or transmit cardholder data, the PCI DSS requirements and testing procedures for wireless environments apply and must be performed (for example requirements 1.2.3, 2.1.1 and 4.1.1). Therefore, an entity should carefully evaluate the need for the technology against the risk. The standard recommends deploying wireless technology only for non-sensitive data transmission.

A service provider or merchant may use a third-party service provider to store, process or transmit cardholder data on their behalf, or to manage components such as routers, firewalls, databases, physical security, and/or servers. If so, there may be an impact on the security of the cardholder data environment. For such cases, the Report on Compliance (ROC) must document the role of each service provider, clearly identifying which requirements apply to the assessed entity and which apply to the service provider. There are two options for third-party service providers to validate compliance:

  • They can undergo a PCI DSS assessment on their own
  • They will need to have their services reviewed during the course of each of their customers’ PCI DSS assessments

Requirements
The standard defines 12 main requirements which must be fulfilled by companies involved with cardholder data processing. On a high level view, the following requirements must be met:

  • Build and Maintain a Secure Network (Requirements 1 and 2)
  • Protect Cardholder Data (Requirement 3 and 4)
  • Maintain a Vulnerability Management Program (Requirement 5 and 6)
  • Implement Strong Access Control Measures (Requirement 7, 8 and 9)
  • Regularly Monitor and Test Networks (Requirement 10 and 11)
  • Maintain an Information Security Policy (Requirement 12)

For the rest of this article, we’ll have a look at the details on each requirement.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Most of these requirements cover aspects of firewall and router configuration. To fulfill these requirements, your network must be well segmented and protected by firewalls. Also all your internet connections must be protected by firewalls (at least). In my opinion, this is best practice since a long time.

You’ll also need proper processes for firewall and router configuration changes. Always document this stuff. Define responsibilities. You must also prove, that you review your firewall and router configuration at least every six months (requirement 1.1.6). So, there are some documentation tasks.

If you run a DMZ (and most companies do), make sure you adhere to best practices for that.

Per requirement 1.3.7 it is not allowed to place systems that store cardholder data (such as databases) in the DMZ. Place them in an internal network zone.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
This requirement mainly verifies that system components are not running with default factory settings. This could allow attackers to easily get access to these components. Basically, there is not much to say about that. Each system administrator should now that. But when time is running out, mistakes are made. At least review your devices for default passwords and weak encryption and change that.

Requirement 2.2 is interesting. It requires you to create configuration standards for all system components. They must meet all known security vulnerabilities and must be consistent with industry-accepted system hardening standards. The standard recommends some standards for hardening system components. There are standards from these organisations:

  • Center for Internet Security (CIS)
  • International Organization for Standardization (ISO)
  • SysAdmin Audut Network Security (SANS) Institute
  • National Institute of Standards Technology (NIST)

Note: One important point, as mentioned in requirement 2.2.1, is to always implement only one primary function per server. This makes assigning a security level for a certain server much easier. Based on the assigned security level, an appropriate network zone is chosen (internal zone, secure server zone, dmz, …).

Requirement 3: Protect stored cardholder data
Cardholder data must be protected. The standard mentions several possibilities such as encryption, truncation, masking or hashing.

You should store cardholder data only if absolutely necessary. If you do not need the full PAN, then encrypt, hash, mask or truncate it. If an attacker steals your data, he cannot get any value out of it.

Per requirement 3.2.2 you are not allowed to store the card verification code (CVV2, CVC2, CID, CAV2 data). So, never ever store this data. In the other case you’ll get into trouble.

Per requirement 3.2.3 you’re also not allowed to store PIN’s or encrypted PIN blocks.

Requirement 3.3: Mask PANs when you need to display them (for example, on screen, on paper receipts). The first six and last four digits are the maximum number of digits to be displayed.

PANs must me stored in an unreadable format, always (requirement 3.4).

Requirement 4: Encrypt transmission of cardholder data across open, public networks
When transmitting cardholder data over untrusted, public networks, you must apply strong cryptography for transmission. The PCI Security Standards Council defines “strong cryptography” as follows:

“Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57”. This was taken from [6].

Requirement 5: Use and regularly update anti-virus software or programs
As mentioned by the standards document, malware often enters a network through business-activities like email and use of internet (surfing), mobile computers and storage devices.

You must deploy anti-virus software on all systems commonly affected by malicious software. This includes personal computers and servers. Verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, trojans, worms, spyware, adware, and rootkits).

Note: It should be clear, that freeware-scanners mostly do not meet these requirements, since they often lack some of the above mentioned features. Go for an enterprise anti-virus solution.

Requirement 6: Develop and maintain secure systems and applications
Attackers often exploit security vulnerabilities to gain privileged access to systems. Vendors usually build security patches to fix these vulnerabilities. Makek sure that all your systems run on a current patch level. Establish a patch management process which ensures, that patches are applied on a regularly basis. Do not wait more than 30 days before applying the patches.

Review custom code prior to release to production in order to identify any potential coding vulnerability (requirement 6.3.2). Make sure, code is reviewed this way:

  • Code changes are reviewed by individuals other than the originating author, and by individuals who are knowledgeable in code review techniques and secure coding practices.
  • Code reviews ensure code is developed according to secure coding guidelines.
  • Code review results are reviewed and approved by management prior to release.

Note: I think the important thing here is to have someone being aware of common mistakes made during development. This person should have a good understanding of coding errors.

You also need to separate development/test and production environment. Access controls must be in place to enforce separation (requirement 6.4.1).

The standard requires you to create custom code according to secure coding practices. They give you some examples::

  • OWASP Guide
  • SANS CWE Top 25
  • CERT Secure Coding

Note: Train your developers in secure coding techniques. This requires time and money (people often forget).

Requirement 6.6 says that public facing web applications must be protected in either of these ways:

  • Do a manual or automated application security assessment
  • Install a web application firewall (WAF) in front of them

Note: I think that none of the above proposed tactics is good enough. These days, attacks are mostly through web applications. Therefore it is the best solutions to deploy a web application firewall AND do application security assessments on a regularly basis.

Requirement 7: Restrict access to cardholder data by business need to know
Make sure, that you always the “need to know” principle. Grant access rights only, if they are really needed. Also make sure that privileges are assigned based on job classification and function (also called “role-based access control” or RBAC).

Requirement 8: Assign a unique ID to each person with computer access
Always assign a unique identification (ID) to each person with access to computers. This ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions performed on critical data is traceable.

In order to meet requirement 8.2, you must employ at least one of the following methods to authenticate all users accessing cardholder data environments:

  • Something you know, such as a password or passphrase
  • Something you have, such as a token device or smart card
  • Something you are, such as a biometric

For remote access users, the requirements are, that you have to combine two of the above methods, when authenticating users (called two-factor authentication):

The standard says: “Two-factor authentication requires that two of the three authentication methods (see requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.”

Note: It is clearly stated, that you must use two different authentication factors in order to meet requirement 8.3. So, use a passphrase and a token device, as an example.

It is prohibited to use shared accounts (group accounts). See requirement 8.5.8. Change your passwords at least every 90 days (requirement 8.5.9). Require a minimum password length of at least seven characters (requirement 8.5.10). Use passwords containing both numeric and alphanumeric characters (requirement 8.5.11). Lockout the user after six unsuccessful login attempts (requirement 8.5.13). Lockout time shall be at least 30 minutes (requirement 8.5.14).

Requirement 9: Restrict physical access to cardholder data
Requirement 9 is all about physical security like using appropriate entry controls, using video cameras.

One important point is requirement 9.1.2. Restrict physical access to publicly accessible network jacks (for example, areas accessible for visitors). The same applies to wireless equipment.

Requirement 10: Track and monitor all access to network resources and cardholder data
Employ logging mechanisms and the ability to track user activities. This is critical in preventing, detecting or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting and analysis when something goes wrong. Witout system logs, you will probably fail.

To meet requirement 10.2 you must implement automated logging trails for all system components to reconstruct the following events:

  • All individual accesses to cardholder data
  • All actions taken by any individual with root or administrative privileges
  • Access to all audit trails
  • Invalid logical access attempts
  • Use of identification and authentication mechanisms
  • Initialization of the audit logs
  • Creation and deletion of sytem-level objects

A single audit log entry must at least contain the following information:

  • User identification
  • Type of event
  • Date and time
  • Success or failure indication
  • Origination of event
  • Identity or name of affected data, system component or resource

Note: Requirement 10.4.1 needs you to run all critical systems using a correct time. Apply time synchronization technology, like NTP.

You must also secure your audit trail logs, so they cannot be altered (requirement 10.5). You should backup them to a centralized log server or media that is difficult to alter. You also need to write logs for external-facing technologies onto a log server on the internal LAN.

You must retain your audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup) (requirement 10.7).

Requirement 11: Regularly test security systems and processes
Test your system components frequently as new vulnerabilities are discovered each day. Run internal and external vulnerability scans at least quarterly and after any significant change (requirement 11.2).

Make sure, no vulnerabilities exist that are scored greated than a 4.0 by the CVSS. For internal scans, a passing result is obtained when all “high” vulnerabilities as defined in PCI DSS requirement 6.2 are resolved.

You must perform network-layer and application-layer penetration tests (requirements 11.3.1 and 11.3.2).

You must use intrusion-detection systems and/or intrusion-prevention systems to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment.

Use file-integrity monitoring tools to alert personnel to unauthorized modification of critical system files, configuration files, or content files (requirement 11.5).

Requirement 12: Maintain a policy that addresses information security for all personnel
Maintain a security policy that sets the tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.

You must implement a formal security awareness program to make all personnel aware of the importance of cardholder data security. Educate personnel upon hire and at least annually.

Remarks
This article gave you an insight into the requirements which must be fulfilled in order to meet PCI DSS compliance. Of course, this article does not cover every requirement in the standards documentation, but focuses, at least in my opinion, on some important aspects.

Feedback Welcome
If you find any errors inside this document or think that something does not reflect the truth, please leave a comment on this article. Thank you very much.

[1] http://www.pcisecuritystandars.org
[2] https://www.pcisecuritystandards.org/security_standards/glossary.php#S

Leave a Reply

Your email address will not be published. Required fields are marked *

*