Understand the terms |
A security standard, implemented by the PCI Security Standards Council for all card brands, to protect customer account data.
It includes requirements for security management, policies, procedures, network architecture, software design, and other protective measures to help facilitate the broad adoption of consistent data security measures.
PCI Security Standards Council
A council founded by American Express, Discover, Financial Services, JCB, MasterCard Worldwide, and Visa International to enhance payment account data security by fostering broad adoption of the PCI Security Standards.
* PABP (Payment Application Best Practices)
A set of requirements a developer’s point-of-sale payment application must comply with to be considered secure. For a list of POS system developers who have gone the extra mile to become validated by an independent, Visa-certified security assessor, go to www.visa.com/pabp
* Note: In 2008, the PCI Security Council will adopt and manage Visa’s PABP security program, making PABP industry wide. PABP is now known as PA-DSS (Payment Application Data Security Standard).
This standard complements the PCI-DSS. It outlines the rules and regulations governing the approval of security for PIN Entry Devices (PED). It’s designed for PIN Pad manufacturing, setup and use. It can be considered complementary to the PCI-DSS. By following this document, those companies and entities that focus primarily on PEDs can more easily and effectively validate the security of their products. Some card associations such as Visa require the use of PED approved devices. However, there’s a matrix of PED certification versions and corresponding dates governing their deployment and use. The PCI PED is periodically updated and with each revision, gets a new version number (i.e. PCI PED v 1).
Note: Originally, the PED security standard was created by Visa and approved devices were referred to as “Visa PED Approved Devices”. Later, it was adopted by PCI and named “PCI PED.”
Level 1, 2, 3, 4 Merchants
The level assigned to merchants based on Visa transaction volume over a 12-month period.
Compliance requirements by level
Level 1
Annual onsite PCI DSS assessment by merchant’s internal auditor or qualified security assessor, or an internal audit, which must be signed by an officer of the company, in addition to a quarterly network security scan done by an approved scanning vendor.
Level 2
Completion of PCI DSS self-assessment questionnaire annually, and a quarterly network security scan done by an approved scanning vendor.
Level 3
Completion of the PCI DSS self-assessment questionnaire annually and a quarterly network security scan done by an approved scanning vendor. As of 10/01/08, all newly boarded merchants must use a PABP compliant application.
Level 4
Completion of the PCI DSS self-assessment questionnaire annually and a quarterly network security scan done by an approved scanning vendor. As of 10/01/08, all newly boarded merchants must use a PABP compliant application.
Understand why
Other Data Security Laws
US Federal Laws
The Fair and Accurate Credit Transaction Act of 2003 (FACTA)
This law dictates among other things that “no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction.”
Note: Currently, there is no federal law dictating the storage of card data. Also, PCI guidelines are stricter, so as long as you abide by their rules, you’re safe with this law. For more information go to “Printing, Storing and Displaying Card Data.”
US State Laws
Tennessee - Tennessee Consumer Protection Act
As of January 2007, “no person that accepts credit cards or debit cards for the transaction of business shall print or cause to be printed more than five (5) digits of the card number or the expiration date upon either the receipt retained by the merchant or the receipt provided to the cardholder at the point of the sale or transaction.”
Note: This law is more restrictive than the federal law and should be blended with PCI requirements. For more information go to “Printing, Storing and Displaying Card Data.”
California – Song-Beverly Credit Card Act of 1971, section 1747.09
As of January 2009, a law with the same limitations as that of Tennessee’s law will go into effect.
Note: This law is more restrictive than the federal law and should be blended with PCI requirements. More information is presented later in this paper, in the section titled, “Printing, Storing and Displaying Card Data.”
Federal - Personal Information Protection and Electronic Documents Act (PIPEDA)
Alberta - Personal Information Protection Act
British Columbia - Personal Information Protection Act
Quebec - An Act Respecting the Protection of Personal Information in the Private Sector
There aren’t any Canadian laws that specifically cover the printing of card data. However, it does fall under the privacy laws. In summary, it is not illegal to print card numbers on the customer copy. However, merchants who print the card number on their copy, must have “rigorous procedures in place to protect credit card receipts that contain all the information needed to misuse a credit card ─ name, credit card number and expiry date.”
Note: For more information go to “Printing, Storing and Displaying Card Data.”
Top Five Data Security Vulnerabilities Leading to Compromise
1. Storage of Sensitive Cardholder Data
PCI DSS prohibits the storage of track data, Card Verification Value 2, and Personal Identification Numbers (PINs) or PIN blocks. Track data is encoded and stored on the magnetic stripe on the back of credit cards. This information is needed to complete a transaction, but should not be retained after the transaction. Many older POS systems store this data automatically, making it easy for hackers to obtain the information and commit fraud.
2. Missing or Outdated Security Patches
Software vulnerabilities require security patches to protect against hackers seeking to exploit or uncover deficiencies in software products. Without current security patches, systems become subject to security compromise.
3. Vendor-Supplied Default Settings and Passwords
Hardware and software products come packaged from vendors with default or blank settings and passwords for ease of installation and management. If these settings and passwords are not changed when they are deployed, it creates an opportunity for hackers to exploit the system.
4. SQL Injection
SQL injection is a technique used to exploit Web-based applications such as shopping cart products. SQL injection attacks can result in the compromise of the payment application or an entire e-commerce site, including the theft of data.
5. Unnecessary and Vulnerable Services on Servers
Servers are often shipped by vendors with additional services and applications that are enabled by default and may be unnecessary. Such applications may be ignored by the system administrator, and neglect to have necessary security patches put in place to protect access to the server.
Click here for more information and strategies to reduce risk for these vulnerabilities.
Remote Access Software Safety
Remote access to POS systems, if not configured and managed correctly, can provide an easy entry point for unauthorized intruders to gain access to the POS system and potentially to sensitive credit card data. Securing access is extremely important and can be managed effectively by following some basic rules.
1. Limit the number of people that can access the system remotely. Only allow and provide remote access to those that have a strong business need. This typically includes the POS system vendor/reseller for remote service and may also include owners, management and administrators of the merchant location.
2. Do not share remote access credentials. Ensure that each user with remote access has a unique username and password..
3. Disable remote access user accounts when no longer needed.
4. Utilize two-factor authentication whenever possible.
5. Never leave remote access software on and "listening" for incoming connections. It is always best to select a remote access package that requires a user at the merchant site to start or log on to initiate a remote access session.
Contact Mercury for information and assistance.
800-846-4472
