Payment Industry Acronym Refresh

The payments industry is full of abbreviations and acronyms.  Let’s take a look at the 5 most common ones we use and their definitions.

  1. PCI DSS stands for Payment Card Industry Data Security Standard – A set of security requirements for all businesses that handle payment cards, including merchants and software developers of applications that handle payment card data. 
  2. P2PE is the acronym for point-to-point encryption.  P2PE ensures sensitive cardholder data is protected from first card swipe or key-entry, while in transit, all the way to the payment processor.  Encryption renders the credit card data so that it is unreadable and valueless should it become intercepted during the transaction life cycle.
  3. POE, known as Point-of-Entry is the initial instance when cardholder data enters the point of sale through a payment device by swiping or manually keying a payment card.
  4. CDE stands for cardholder data environment.  A merchant’s CDE is made up of all of the components used to process, store, or transmit cardholder data.  
  5. EMV stands for Europay, MasterCard, and Visa.  Named for the organizations that originally backed the initial development, EMV is the transaction protocol that uses microchips on payment cards to authenticate the card vs. traditional magstripe data.


Implementing a Strong Password Requirement -- Part II

As we have seen, the Payment Card Industry Data Security Standard (PCI DSS) requires businesses to utilize alphanumeric passwords of seven or more characters.  This is certainly a sound practice—but password security involves additional aspects that are also vital for maintaining PCI compliance.  Let’s take a look at the various other password requirements set in place by the PCI DSS.

Requirement 8.2.4 of the PCI DSS calls for organizations to change system passwords every 90 days, if not sooner.  An account-lockout policy is also an important component of a business’s overall data security strategy.  This involves locking a particular account—that is, preventing further access attempts—after a certain number of failed login attempts.  Requirement 8.1.6 requires  organizations to lock accounts after no more than six failed log-ins.  The account should remain locked until at least thirty minutes have passed or a system administrator reactivates it.

The account should also be set to require a user to reauthenticate their identity—i.e., re-enter the password and, if needed, ID name—after the session has been idle for 15 minutes.  If appropriate, the system administrator can set the account to allow an even shorter idle period before demanding reauthentication.


Implementing a Strong Password Requirement -- Part I

The Payment Card Industry Data Security Standard (PCI DSS) provides sound guidance on password requirements for businesses of all sizes.  Requirement 8.2.3 calls for passwords to be at least seven characters long and contain a mixture of alphabetic and numeric characters.  For example, a password such as b56aq8g meets the minimum PCI DSS requirement, while ones like a35r4 (too short), 394958301 (no letters), and abcdefg (no numbers) all fail to comply.

It’s worth emphasizing that the PCI DSS password guideline is the minimum standard with which an organization must comply.  A business is allowed—encouraged, in fact—to go beyond the baseline requirement laid down by the PCI DSS.  Passwords longer than seven characters can provide substantially more security.  However, long passwords carry the disadvantage of being harder to remember.  Also, not all systems can handle unusually long passwords.  If this is a concern, keep in mind that adding just one or two more characters can make the password more secure.

Due to technical limitations, some businesses aren’t able to create the required seven character password for their systems.  For these organizations, the PCI DSS 3.0 allows them to apply an “equivalent strength” standard to create passwords that meet the security level of a seven-character alphanumeric password.  One strategy to bolster the strength of an inadequate password is to use one or more symbol characters (e.g., @, !, &) if the system supports this option.


Maintaining a System Component Inventory

It is important to maintainin an up-to-date payment processing environment  and keepkeep track of all of the various components that make up the environment.  Nowadays, businesses find themselves juggling an ever-increasing number of hardware and software products, and keeping a proper system component inventory can seem like more trouble than it’s worth—but this type of inventory is an essential part of any company’s data security plan.  It is also required by the PCI Data Security Standard (PCI DSS) under Requirement 2.4.

The Standard requires PCI-compliant businesses to “maintain an inventory of system components that are in scope for PCI DSS.”  There are two practices that a business should follow to ensure that this happens: 

  • The list should be checked on a regular basis to test whether it is properly maintained.  It should include not just a simple listing of products, but also a description of each item and its function. 
  • The company should regularly consult with relevant personnel to ensure that the list is continually updated.


New PCI DSS Session Management Requirements

Authentication and session management is an aspect of data security relating to the regulation of user interaction within a system such as log-in procedures, session cookies, time-out policies, and similar elements.  The suboptimal implementation of these elements can pose a security risk, allowing unauthorized persons to gain access to areas and systems where they do not belong.  Broken authentication and session management has never been explicitly covered in the PCI Data Security Standard (PCI DSS).  Version 3.0 of the PCI DSS includes the brand-new Requirement 6.5.10, which calls for organizations to regulate this aspect of their internal and external application interfaces.  This requirement joins preexisting instructions that governed cross-site scripting (6.5.7), improper access control (6.5.8), and cross-site request forgery (6.5.9).

This new requirement directs businesses to interview relevant personnel and consult applicable documentation to guarantee proper authentication and session management.  Version 3.0 mentions three specific examples of session management techniques that should be implemented: 

  • Marking cookies and other session cookies as secure 
  • Ensuring that the session ID doesn't appear in the URL 
  • Applying session time-outs and rotating IDs

A PCI compliant organization should take steps to ensure that keys, account credentials, and session tokens cannot be exploited by unauthorized personnel.  Incidentally, those who worry about this new guideline should be aware that Requirement 6.5.10 is listed as a best practice until June 30, 2015; it does not become a requirement until after this date.


New Anti-Malware Requirements in PCI DSS 3.0

The release of the Payment Card Industry Data Security Standard (PCI DSS) 3.0 has brought a variety of tweaks and modifications to the established data security guidelines.  One portion of  that has been updated is Requirement 5, which addresses the proper procedures for maintaining anti-virus software and programs. Version 3.0 avoids making massive changes in this particular area, but the revisions to Requirement 5 are significant and worthy of note.

Among these revisions is the addition of Requirement 5.1.2.  This new section calls for businesses to "perform periodic evaluations to identify and evaluate evolving malware threats" in order to ensure the continued safety of systems that are generally unaffected by  Internet-based hazards.  The addendum complements the preexisting Requirement 5.1, which compels organizations to use up-to-date anti-virus programs to protect systems "commonly affected by malicious software."  The change is acknowledgement of the fact that hackers and other cybercriminals continually invent new and improved ways to obtain sensitive data; a system that may be reasonably secure, today, could easily be targeted for exploitation, tomorrow.  Therefore, businesses are now required to monitor emerging cyber threats to ascertain whether a given system should be granted protection by an anti-virus program. Monitoring may be carried out in a number of ways, from checking Internet newsgroups, to reviewing security notices from vendors. 

Requirement 5.3 is another addition to the PCI DSS; this calls for organizations to ensure that anti-virus programs cannot be changed or turned off except as a temporary measure to address technical needs, and then only by authorized personnel whose approval to do so is granted on a case-by-case basis.  This expands on the previous version, which simply stated that businesses must ensure that their anti-virus programs remain "actively running." 


How to Prioritize Patch Updates

It seems as if hardly a week goes by without hearing news of some potentially catastrophic "zero day" vulnerability that threatens to turn our computers into playgrounds for nosy hackers. To ensure PCI compliance, it's essential for merchants to install security patches on a regular basis to guarantee up-to-date protection against system weaknesses. Neglecting to carry out this operation properly can cause several problems for businesses. An organization that ignores security updates could not only fall victim to a data breach but fall out of PCI compliance as well.   Businesses that still utilize Windows XP are being urged to upgrade to a more recent operating system--Microsoft will end of life XP operating system in 2014, which means security patches will also cease.

The PCI Data Security Standard (PCI DSS) requires businesses to install security updates within one month of release. Merchants should maintain a written policy that ensures compliance with this requirement. Furthermore, companies should have a list of security updates that have been applied to their systems; this should be checked against the most recent vendor-supplied security patch list to make sure that nothing has been overlooked.

Sometimes businesses have trouble applying these patches in a timely fashion. Harried IT personnel may be pleased to learn that the PCI DSS acknowledges this difficulty and allows for an optional "risk-based" approach to installing patches. Businesses may prioritize their security updates by arranging their various system components in a hierarchy, in which the most critical components are scheduled to receive updates sooner than less critical ones. Under this system, highly critical components (e.g., customer-facing systems) will still be updated with relevant security patches within the standard one-month period, but less critical devices can delay installing them for up to three months. Data-security personnel who are pressed for time can concentrate on addressing the important systems, without fear of violating the PCI DSS. 


When Does the PCI DSS Apply?

Since the release of version 1.0 in December 2004, the PCI Data Security Standard (PCI DSS) has been hugely influential in making payment card transactions safer for everyone.  Even so, some in the business community remain a bit flummoxed by this large, frequently updated document, with its twelve requirements that each contain a variety of subsections. The PCI DSS is less imposing than it may seem at first glance.  In fact, it can be said that its various aspects are all designed to achieve one specific goal:  protecting  cardholder data.  This data -- the (usually) 16-digit number printed across the front of a credit or debit card -- is the most important type of information associated with payment processing, and its proper handling is the main focus of the PCI DSS.  The document governs the proper handling of payment account numbers (PANs) through every stage of their use -- processing them, transmitting them, and storing them. 

If a business never handles PANs in any way, which is sometimes the case with small, cash-only merchants, then it is exempt from the requirements of the PCI DSS.  Businesses of this kind are increasingly uncommon these days, though, so it's very probable that you have to contend with the PCI DSS

The unique importance of the PAN explains why it is subject to security requirements above and beyond those that are considered non sensitive data (e.g.,cardholder name, card expiration date).  The PCI DSS calls for PANs to be stored (if they are to be stored at all) in a manner that renders them unreadable, which can be achieved through tokenization


Characteristics of an ASV Scan

Requirement 11.2.2 of the PCI Data Security Standard (PCI DSS) compels merchants to “perform quarterly external vulnerability scans via an Approved Scanning Vendor (ASV).”  The purpose of these scans is to ensure that a company maintains up-to-date security measures that can protect its systems against the most recent cyber threats.  For many, these vulnerability scans are a bit of a mystery—most people understand that the scan itself helps ferret out security weaknesses in an organization’s system, but they’re unsure what exactly goes on during this procedure.  To clear up this confusion, we can turn to the PCI Security Standards Council, which has helpfully provided some answers in its “Approved Scanning Vendors Program Guide (Version 2.0).”

The ASV Guide sets forth a series of General Guidelines that ASV scans must follow.  Keep in mind that Approved Scanning Vendors get their certification through the PCI SSC, so these guidelines must be followed if the ASV is to remain listed on the Council’s site.  According to the Council, ASV scans must:


  • “Be Non-Disruptive”—ASV scans must not interfere with the normal functioning of a company’s systems.  Tests forbidden by the PCI SSC include those that involve buffer overflow exploits, rootkit installation, or interference with DNS servers.


  • “Perform Service Discovery”—The ASV must perform a scan on all Transmission Control Protocol (TCP) ports and common User Datagram Protocol (UDP) ports.


  • “Perform Host Discovery”—The ASV must attempt to ID live systems.


  • “Perform OS and Service Fingerprinting”—The scan should ID the operating system associated with each live system and ID the protocol and application version associated with each open port.


  • “Have Platform Independence”—The ASV scan must be applicable to all common platforms.


  • “Account for Load Balancers”—The ASV’s report must detail the client’s use of load balancers.  If necessary, relevant documentation should be obtained from the client.


  • “Be Accurate”—The ASV has a responsibility to report all confirmed and potential vulnerabilities.


The Hazards of Default Passwords

The kinds of hardware and software commonly used by merchants, such as a point-of-sale (POS) application, generally comes with a simple default password and setting to allow easy initial access.  But many users make the grave mistake of failing to change these default passwords and settings—this leaves devices and applications vulnerable to hackers and other unauthorized persons.  Lists of default passwords, encryption keys, and SNMP settings used on specific devices circulate widely among hackers; a business that retains these defaults effectively leaves a door open for troublemakers.  Furthermore, retaining default settings means a business falls out of PCI compliance, as the Payment Card Industry Data Security Standard (PCI DSS) calls for these to be changed “before installing a system on the network” (PCI DSS requirement 2).  Default passwords must be updated as soon as possible, and should meet the following requirements in order to maintain PCI compliance:


  • Must be updated every 90 days
  • Must be a minimum of seven characters
  • Must contain both alpha and numeric characters

Search Blog

Your email address:

Bookmark and Share


About PCI DSS Compliance Blog

Email Us

PCI Compliance Resources

Industry News on Twitter

Visit Element on