My Merchant Account Blog

PCI Compliance - A Review of Consumer Benefits

Wednesday, November 30, 2011

Credit cards are a must have for small and medium sized businesses today. Without them, businesses will lose out on higher revenue, improved customer service and overall faster growth. Unfortunately, with all these merchant account benefits comes the increased risk of fraud, which if not addressed properly, can negatively affect the financial position of your business.

Seven years ago, in 2004, MasterCard, Visa, Amex, Discover and JCB International developed a security council for implementing standardized security measures to reduce credit card processing fraud. The standards included the Data Security Standard, PIN Transaction Security Requirements, and the Payment Application Data Security Standard. This post will address the council’s successes and what the benefits have been for consumers and merchants since the council’s inception in 2004.

Procedures for Supporting a Secure Network

The security standards were one of the first changes that was made when the PCI council was created. The driving force behind the security standards was to protect credit card data from thieves and hackers. Some of the action items that were implemented was a more robust firewall for protecting data on the cloud and improving procedures for accessing password-protected information on private accounts. Testing is another procedure the PCI Council has implemented. They constantly examine their network for liabilities and look for ways to improve their protection over consumer data. The network is also monitored for weaknesses that may lead to a breach in the future. Overall, the council has successfully implemented new procedures and monitoring protocol.

New Security Measures for Protecting Credit Card Data

The transmission and storage of credit card data has been improved by the PCI council. The way they improved the transfer of data was by encryption so third parties cannot access the information. Over the last year, the number of online hackings have increased. If these procedures were not implemented when they were, credit card data would be at the mercy of organized crime.

Controlling the Way Data Flows

Business owners no longer have the same kind of access to credit card information as they used to. Data is now accessed on a need-to-know basis, which means there are processes the merchant must follow to access the information. Only employees who have permission will be able to pull data from the system. This measure was put in place to reduced employee fraud. After mentioning all these standards and procedures that the PCI council developed and implemented, it is important to examine what the real benefits are for the merchants. Below are a few examples of direct benefits that were incurred since the inception of the council.

Improved Consumer Trust Results in More Revenue

Plainly put, it is proven that consumer trust will result in higher revenue for a merchant. For this reason, it is important that all measures are taken to reduce fraud. This trust is most critical for e-commerce businesses, where fraud is most prevalent. Since the e-commerce industry is very competitive, it is important that a business owner take advantage of each opportunity to save money and build a customer base. With the security measures put in place today, credit card fraud should not jeopardize the success of a business.

Zero Merchant Risk

Without an EMV terminal (a terminal that complies with the PCI council) merchants are at risk of paying expensive fines if fraud occurs. Merchants may also be liable to pay investigators to identify the source of the breach. To avoid this unnecessary cost, merchants must become PCI compliant, or in other words, process with a chip and PIN terminal, and all the liability is eliminated. Unfortunately, many merchants believe they are PCI compliant but in fact are not. For example, 77% of hospitality merchants think they are compliant but in fact are not. This article should serve as a reminder why merchants should be PCI compliant and how much good the council has been for the credit card processing industry.

PCI DSS Version 2 Announced

Thursday, January 06, 2011

Even though some merchants might already be using PCI DSS v2, they were formally published effective January 1, 2011.  Merchants can still use PCI DSS 1.2.1 until December 31, 2011.  In an effort to help merchants understand PCI DSS, it published a new website and a 61-page Navigating PCI DSS: Understanding the Intent of the Requirements version 2.

While My Merchant Account Blog appreciates it readers, we also suggest that merchants check out the PCI Security Standards Council's website for information as well.  Their website will have current information regarding the standards.  We will continue to archive their standards and you can view them anytime needed.

PCI Myths

Thursday, December 11, 2008

Now that we have talked about PCI Compliance and the six cores:

1. Build and Maintain a Secure Network
2. Protect Cardholder Data
3. Maintain a Vulnerability Management Program
4. Implement Strong Access Control Measures
5. Regularly Monitor and Test Networks
6. Maintain an Information Security Policy

Let us look at a few myths.  These myths could cost you thousands of dollars in fines.

Hackers Only Target Large Companies

Some merchants might think that breaches only happen to the large corporations.  Part of this is true - breaches do happen to large corporations, but smaller merchants are just as vulnerable.  If you have a shopping cart and the code is not kept up-to-date, this could leave you wide open for a data compromise.  If you are storing any cardholder data (the primary account number along with the cardholder's name or expiration date), you need to be PCI compliant.

Processing is Done on the Gateway (or Third Party)

The transaction is done on the electronic payment gateway's secure website or third party processor (3PP) / Internet Payment Service Provider (IPSP) and they are PCI compliant.  This does not mean you are compliant or exempt.  PCI Compliancy is an ongoing process.  The PCI DSS requirements and security assessment procedures include the data security, physical security, and your security policies.

For example, the CISP Compliant list from Visa (3 May 2007), shows that Google Checkout was late in reporting their compliancy to Visa.  And on the 15 Jul 07 CISP Compliant list, Google Checkout was removed because they were over 90 days to file their report.  On the 15 Nov 08 Visa CISP Compliant list, Google Checkout is listed

The Shopping Cart and Hosting Company are PCI Compliant

The shopping cart and hosting company are just a part of being PCI Compliant.  As stated above, it covers your security policies and how you handle the transactions.  For example, your security policy should address how your employees handle cardholder data if an order is taken over the phone.

PCI Only Applies to the IT Department

Unfortunately, this is not the case.  In the example above, the employee handling the order on the telephone is in the sales department.  PCI Compliancy covers all individuals in your company that handle, process, store, or transmit the cardholder data.

We Only Handle Two Orders a Month

Breaches can happen to any company, no matter the size.  Since your company has access to cardholder data, you need to be PCI Compliant.

PCI Compliancy Is Too Much

While the guidelines seem intimidating, most of them are probably already being done by your company.  The guidelines help you with the specifics and an effective way to secure cardholder data.

We Are PCI Compliant

Just because you have completed the self-assessment questionnaire and had a company scan your website does not mean you are protected from breaches.  Compromises can still happen to a PCI Compliant merchant.

Maintain an Information Security Policy

Monday, December 08, 2008

The last core of Payment Card Industry Data Security Standard (PCI DSS) only has one requirement

• Maintain an Information Security Policy

Companies should have a strong security policy in place that all employees should sign and abide to.  The employees should understand the sensitivity of the data and what their responsibilities are in protecting this data.  The security policy should be followed stringently.  New employees should be made aware of the security policies and made to sign they understand their duties and responsibilities.

The policy should assign a team or individual to security management to ensure policies are disseminated accordingly.

The policy should address what happens when a compromise occurs.  It should help to identify who should be called, no matter the time of day.  The plan should include continuity procedures, data backup processes, roles and responsibilities, and a contact strategy (for example, contacting the credit card associations).

You should also review the PCI DSS Requirements and Security Assessment Procedures for the complete requirement.  It will go into complete detail of what your information security policy should contain.

Regularly Monitor and Test Networks

Sunday, December 07, 2008

The fifth core of Payment Card Industry Data Security Standard (PCI DSS) consists of two requirements:

• Track and monitor all access to network resources and cardholder data
• Regularly test security systems and processes

Track and Monitor All Access to Network Resources and Cardholder Data

We have said it in the past few posts, but it bears saying again.  Audit trail history should be retained for at least one.  These logs should provide the company with a

• Unique User Identification
• Type of Event
• Date and Time
• Origination of Event
• Success or Failure Indication
• Identity / Name of Affected Data, System Components, Resources

These logs should be secure and unable to be altered by anyone and have limited viewing.  Times on all systems should be synchronized.  Logs should be reviewed daily for unknown events.  It sometimes takes days or weeks before a breach is reported by a cardholder.

Regularly Test Security Systems and Processes

Systems should be scanned to discover potential vulnerabilities.  A vulnerability scan is an automated tool run against external and internal access points and servers on the network that will help identify ports and vulnerabilities that could be exploited by hackers.  If any vulnerabilities are detected, steps should be taken to fix them immediately.  Network intrusion detection systems should also be in place.

Approved Scanning Vendor

Most merchants will be required to do have a quarterly scan completed by an Approved Scanning Vendor (ASV). Approved Scanning Vendors (ASV) can complete the quarterly scan for your company.  Only choose a vendor that is listed Approved Scanning Vendors web page.  Otherwise, you might compromise your data or the scan will not be accepted by the council.  The scan requirements are quite rigid - all 65,535 ports will be scanned.  Any vulnerability that is rated between three to five must be fixed.  You will also get two reports:

• An executive summary report with a PCI approved compliance statement suitable for submission to acquiring banks for validation
• A technical report that details all vulnerabilities detected with solutions

Selecting a PCI Network Security Testing Service

While there are a number of Approved Scanning Vendors listed, there are three critical things to look for when choosing a company:

1. Accuracy:  False positives can increase the activities and costs that are associated with these false positives (and even false positives).  You do not want the company to generate a large number of false positives / false negatives that will increase the amount of time you have to work through each issue.
2. Efficient Vulnerability Remediation Process:  The company should offer technical support to fix each issue found.
3. Automated Report Preparation and On-Line Filing:  This will reduce your work and time you spend on getting PCI compliance if the company offers automatic preparation and electronically filing.

Qualified Security Assessor

Large merchants that are considered Level One (or merchants that have had a data breach) are required to have an on-site security audit performed by a Qualified Security Assessor (QSV).  These vendors are authorized to perform the annual audits. QSAs are companies that assist organizations in reviewing the security of its payments transaction systems and have trained personnel and processes to assess and validate compliance with PCI DSS.

Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard (PCI DSS) is the global standard that any business of any size should abide by in order to accept credit cards.  This includes storing or processing any cardholder data.

Businesses should access any type of vulnerability that might pose a compromise of cardholder data.  This vulnerability could be in the process or transmission of the cardholder information.  It could also be when the card is given to an employee to scan. 

Once the vulnerabilities are identified, steps should be taken immediately to fix any vulnerabilities, i.e. software code and updates.  All steps should be documented and back-out procedures in place just in case.

Regular reports are required to be submitted to the acquiring bank and card associations.  A quarterly scan report is required by a Approved Scanning Vendor (ASV).  Businesses that do have a high number of transactions might also be required to have a annual on-site audit by a Qualified Security Assessor (QSA).

Complying with PCI DSS

While the card organizations came together to help form the PCI DSS council to help set the standards, each card association (brand) has its own security program for compliance:

• MasterCard Worldwide: Standard Data Protection (SDP)
• American Express: Data Security Operating Policy (DSOP)
• Discover Financial Services: Discover Information Security & Compliance (DISC)
• Visa Incorporated: Cardholder Information Security Program (CISP)
• JCB International: JCB Data Security Program

Implement Strong Access Control Measures

Saturday, December 06, 2008

The fourth core of PCI DSS is Implement Strong Access Control Measures and is comprised of three requirements:

• Restrict access to cardholder data by business need-to-know
• Assign a unique ID to each person with computer access
• Restrict physical access to cardholder data

This can be accomplished easily by ensuring each employee has his / her own unique ID to sign into the systems.  Ensure that the employee has access to only what he / she needs.  For example, an employee who is assigned to enter / update product information and inventory does not have the need to see the customer / cardholder data.

Restrict Access to Cardholder Data by Business Need-To-Know

As with the example above, the employees' duties need to be fully documented. These duties will help to explain what data the employees needs to have access.  Limiting access to those with a strong business reason for the access will help your organization prevent mishandling of cardholder data through inexperience or malicious intentions.

Assign a Unique ID to Each Person with Computer Access

Each employee should have his / her own unique ID to access your system.  By ensuring each employee has his / her own unique ID, an organization can maintain individual responsibility for actions and have an audit trail per employee.  Do not create generic IDs, i.e. billing, stocking, etc.  Create unique IDs based on the individual, not the job.

The employees should not share their passwords with anyone.  Other methods to authenticate users can be biometrics or token devices.  Two factor authentication should be used for remote access for additional security.  Passwords should always be encrypted during transmission and storage.  Do not allow employees to email their passwords.  Also, verify the identity of the individual before changing a password.  Some hackers might call the help desk claiming they cannot access their account.  Passwords should also be unique for each new individual.  If you use the same password, it might easily be discovered used to gain access.

Terminated employees should be removed from the system immediately.  Policies should be in place by human resources to let the proper department know of the termination.  Accounts should also be monitored for inactivity.  If activity has not occurred within 90 days, the account should be deleted.

As discussed on Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters, passwords should consist of both numeric and alphabetic characters.  Passwords should be at least seven characters and changed every 90 days.  Individuals should not be allowed to use any of the last four passwords.

Restrict Physical Access to Cardholder Data

Facility entry controls should be used and enforced by the organization where cardholder data is stored, processed, or transmitted.  Logs of entry should be maintained for at least three months unless otherwise restricted by law.  Cameras should also be used to monitor sensitive areas.

Visitors

Procedures should be in place to help distinguish between employees and visitors.  A visitor log should be used to maintain a physical audit trail and kept for at least three months (unless prohibited by law). 

Visitors should:

1. Be authorized before entering any area where cardholder data is processed or maintained
2. Be given a badge or access key the specific areas he / she needs to be in and the badge should expire
3. Ensure the visitor returns the badge before leaving

Management and Storage of Paper and Electronic Media

This also includes backups which may contain cardholder data.  You can contract with a commercial data-storage facility or for a smaller entity, consider a safe-deposit box.  Computers, electronic media, networking and communications hardware, telecommunication lines, paper receipts, paper reports, and faxes are some examples that will need to be secured.

The media should be marked confidential and send the media only with a secure courier.  Do not use a system where a tracking system is not in place.  Cardholder data that leaves the facility should be signed for by an authorized person.  Strict control over the storage and accessibility of the media should be maintained at all times.

If the cardholder data is no longer needed for business purposes, it should be destroyed.  Paper can be cross-cut, burned, or turned into pulp.  Electronic media should be purged, degaussed, or shredded so data can no longer be accessed.

Maintain a Vulnerability Management Program

Friday, December 05, 2008

There are two requirements in this third core of PCI DSS (Maintain a Vulnerability Management Program):

• Use and regularly update anti-virus software or programs
• Develop and maintain secure systems and applications

In this core, it helps to know your vulnerabilities / weaknesses and how you can fix them before problems will occur.

Use and Regularly Update Anti-Virus Software or Programs

Anti-virus programs should be installed on each computer that uses your mail server and should be updated consistently.  The anti-virus program should be able to generate logs for you to review to ensure the updates have been applied and if any potential threats were received.  The logs should also be able to tell you what happened to these threats. 

The anti-virus program should also protect your systems of any other malicious software, including spyware, malware, adware.

Develop and Maintain Secure Systems and Applications

Hackers are consistently attempting to find vulnerabilities in software and components.  Security patches should be installed as soon as possible, but no later than one month of its release.  You should subscribe to a service that will inform you of any potential vulnerabilities, like the Multi-State Information Sharing and Analysis Center (MS-ISAC) or CERT.

Development, testing, and production environments should be completely separate since the staging environment is sometimes less secure than the production environment.  Personnel duties should be separated as well to limit the access to cardholder data.  When testing, PANs should not be used.  Some electronic payment gateways will allow you to replicate the transaction process using test credit card numbers.  When you are ready to go live, all test data and custom application accounts / usernames / passwords should be removed.

Change of Record

Change control procedures should be regimented and documented.  These procedures should include:

• Documentation of impact
• Management sign-off by appropriate parties
• Testing of operational functionality
• Back-out procedures

Without the proper change controls in place, a breach could potential occur.  This breach could inadvertently happen based on the employee's experience or background.  Background checks should be adequate to prevent untrustworthy or untrained individuals access to software code.

Secure Coding Guidelines

Software applications and code should be built based on the industry's best practice of secure coding - consider the guidelines at the Open Web Application Security Project (OWASP) or CERT Secure Coding Standards.  Data should be validated before being sent to the web application.  Error handling should also be reviewed.  For example, a username and password is entered into your web application.  An error message is produced saying "incorrect password".  This lets the hacker to assume he now has a username to gain access, and he should focus on a password.  Using more generic error messages like "data could not be verified" would be better.

Build and Maintain a Secure Network

Thursday, December 04, 2008

There are two requirements in the first core of PCI DSS (Build and Maintain a Secure Network)

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

Firewalls can be either hardware or software, but firewall hardware usually tends to be more secure.  Firewalls though are key in helping to protects your servers from hackers.  The firewall should examine all networking traffic and block traffic that does not meet certain requirements.

When you first buy a shopping cart or download a free one, you need a way to access the database.  Usually this is done via web interface in the admin section of the cart.  Most carts give an easy password to enter, like password or 123456.  Merchants must change this password immediately and only allow certain employees access to the data.  Some carts will also allow you to set up users to have access to just specific data, i.e. inventory, mailing list, etc.  If your cart supports this, consider using it as well.

Install and Maintain a Firewall Configuration to Protect Cardholder Data

Usually this requirement is done at the hosting or data center level.  Some hosting and data center companies will tell you they are PCI compliant.  This usually will mean their firewall is set up properly to allow certain protocols besides the Hypertext Transfer Protocol (HTTP), Secure Shell (SSH), Secure Sockets Layer (SSL), Virtual Private Network (VPN), and File Transfer Protocol (FTP).  Compromises usually will happen on unused or insecure ports (remember there are over 60,000 ports and most need to be blocked to avoid exploitations.

There are many protocols that a company might need (or the protocol is enabled by default).  These protocols are used by hackers to breach security in a network.  The protocols should be well documented and justified and security features should be in place, documented, and implemented.  The firewall rules should be reviewed every quarter.

You should also prohibit direct public access between the external networks and any system that might store cardholder data like logs, databases, trace files.

Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

Usually the first step a hacker might try to gain access into your system is the default passwords (password, test, 123456, admin, etc).  These passwords are usually also found on the shopping cart vendor's website FAQ section or in the cart download.  These passwords should be changed before installation or immediately after (to help prevent hackers from possibly creating another administrator user account.

The password that you create should consider of numbers, letters, and special characters.  Try not to use birthdays and family, city and street names.  Your password should be changed at least every six months.  Try not to use your password on any computer that is accessible to the public (library, Internet shop, etc).  Ask your shopping cart vendor if any special characters are not allowed, like ",:,^,&,\,/.  And find out if the password is case sensitive.  This will help to increase the security of your passwords.  Some examples of passwords could be something like

• 0t4ly31p (using numbers and lowercase letters)
• AI6GQ44O (using numbers and uppercase letters)
• lSwSOpf1 (using number and lowercase / uppercase letters
• uq6"=~$i (using number, lower case letters, and symbols)
• 9R1`~hF6x (using numbers, lowercase / uppercase letters, and symbols)

As you can see, these would be more difficult for hackers.  And don't keep your password written down on your desk or anything.

Your server should serve one primary function, i.e. as a web server or database server.  Having your database server on your web server could be at risk since the web server is directly connected to the Internet.

Shared Hosting

Most Level 4 Merchants and some Level 3 Merchants might rely on a hosting company.  Usually these hosting companies will put hundreds, if not thousands, of other websites on the same server.  This is commonly known as shared hosting.  There are some steps the shared hosting company needs to comply with to help you get PCI Compliant:

• If a merchant is allowed to run an application on the server, that application should be ran with that merchant's ID and not a privileged user (which would possibly have access to other merchant's cardholder data.  To ensure that the merchant only has access to their own information
  1. Privileges of the merchant's web server ID
  2. Permissions granted to read, write, and execute files
  3. Permissions granted to write to system binaries
  4. Permissions granted to the merchant's log files
  5. Controls to ensure one merchant cannot monopolize the system resources
• Logs specific to the merchant's cardholder data should be made available to the merchant to ensure no compromises have occurred
• The hosting company must enable a process to provide quick and easy response in the event that a forensic investigation is needed for a potential compromise that is specific to that merchant

Protect Cardholder Data

There are two requirements in this second core of PCI DSS (Protect Cardholder Data):

1. Protect stored cardholder data
2. Encrypt transmission of cardholder data across open, public networks

The Primary Account Number (PAN) should be protected at all times.  The PAN should not be stored unless it is absolutely necessary and should always be encrypted wherever it is stored.

Protect Stored Cardholder Data

A data retention and disposal policy should be created.  Storage and retention should be limited to the time required for business, legal, or regulatory purposes.  However, the CVV2 / CVC2 / CID / CAV2 should not be stored / retained for any purpose.  If this data is stored, it violates the card associations regulations which can lead to fines and penalties.  Your merchant account provider might even add you to the MATCH / TMF list.

It is understood that some employees will have the need to see the PAN from time to time in the course of their duties at work.  Encryption keys should be used to view the PAN.  Key distribution and storage should be secure.  Keys should be changed at least once a year and old keys destroyed.  If you suspect a key has been compromised, it should be replaced immediately.

If for some reason the company is unable to encrypt the cardholder data, refer to Self-Assessment Questionnaire A and Attestation of Compliance: Appendix B.

Encrypt Transmission of Cardholder Data Across Open, Public Networks

Sensitive information must be encrypted during transmission over networks because it is easy for hackers to intercept / divert traffic during the transmission.  Never send unencrypted account numbers by e-mail. 

Winning the PCI Compliancy War

Wednesday, December 03, 2008

A lot of merchants hear PCI DSS (Payment Card Industry Data Security Standard) and figure they don't have anything to worry about.  Unfortunately that is not the case.  Every merchant needs to start reading and learning about PCI.

Let's start with just the basics and later we can talk about the requirements.  MasterCard created their own plan called Security Data Protection (SDP).  Visa actually had two programs: (international) Account Information Security (AIS) and Cardholder Information Security Plan (CISP).  In 2006, five card associations (payment brands) including Visa International, MasterCard, JCB, Discover Financial Services, and American Express came together to jointly form the PCI Security Standards Council.

The PCI DSS requirements apply to merchants, network members, and service provider that store, hold, process, or transmit cardholder data.  There are twelve requirements divided into six categories:

• Build and Maintain a Secure Network
• Protect Cardholder Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

By now, you should know what level you are.  Chances are you are probably Level 4 or maybe Level 3.  In any event, you will need to complete the Self-Assessment Questionnaire A and Attestation of Compliance (PCI DSS version 1.2 PDF) unless you are a Level One merchant.

Approved Scanning Vendors

Approved Scanning Vendors (ASV) can complete the quarterly scan for your company.  Only choose a vendor that is listed Approved Scanning Vendors web page.  Otherwise, you might compromise your data or the scan will not be accepted by the council.  The scan requirements are quite rigid - all 65,535 ports will be scanned.  Any vulnerability that is rated between three to five must be fixed.  You will also get two reports:

• An executive summary report with a PCI approved compliance statement suitable for submission to acquiring banks for validation
• A technical report that details all vulnerabilities detected with solutions

Selecting a PCI Network Security Testing Service

While there are a number of Approved Scanning Vendors listed, there are three critical things to look for when choosing a company:

1. Accuracy:  False positives can increase the activities and costs that are associated with these false positives (and even false positives).  You do not want the company to generate a large number of false positives / false negatives that will increase the amount of time you have to work through each issue.
2. Efficient Vulnerability Remediation Process:  The company should offer technical support to fix each issue found.
3. Automated Report Preparation and On-Line Filing:  This will reduce your work and time you spend on getting PCI compliance if the company offers automatic preparation and electronically filing.

Complying with PCI DSS

While the card organizations came together to help form the PCI DSS council to help set the standards, each card association (brand) has its own security program for compliance:

• MasterCard Worldwide: Standard Data Protection (SDP)
• American Express: Data Security Operating Policy (DSOP)
• Discover Financial Services: Discover Information Security & Compliance (DISC)
• Visa Incorporated: Cardholder Information Security Program (CISP)
• JCB International: JCB Data Security Program

Breaking Down the Levels of PCI DSS

Tuesday, December 02, 2008

The Payment Card Industry Data Security Standard ((PCI DSS) helps to ensure that cardholder data is secure, whether in processing the transaction or storing the credit card number.  PCI has been around for quite a few years, but now more and more merchants are hearing about it.

PCI DSS Merchant Levels

Merchants are divided into four categories:

• Level One: Processing more than six million transactions per year or has had a security breach with cardholder data compromised
• Level Two: Processing less than six million but more than 150,000 per year
• Level Three: Processing less than 150,000 but more than 20,000 transactions per year
• Level Four: Processing less than 20,000 transactions per year

When version 1.1 was released, it combined all transactions instead of separating between Visa and MasterCard transactions.  Also these transactions are determined by your company, not per merchant account.  So let's say Merchant Account A is processing 80,000 transactions a year and Merchant Account B is processing 100,000 transactions a year, you would be considered a Level Two Merchant.

Level One Merchants

Compliance validation has been required for merchants that process over 6 million (Visa) transactions a year since September 30, 2004.  MasterCard required Level One merchants be compliant by June 30, 2005.  An on-site security audit is also required annually with a network scan every quarter.

Level Two Merchants

Visa required Level Two merchants be PCI compliant by September 20, 2007. MasterCard is requiring the Level Two merchants be compliant by December 31, 2008.

Level Three Merchants

Both Visa and MasterCard required Level Three merchants to be compliant by June 30, 2005.

Level Four Merchants

There is no set date for Level Four merchants.  This is determined by your merchant account provider or the acquiring bank.  However, if you are not compliant and a breach occurs, you can be fined $500,000 or more by the card associations.  If you are compliant and compromised, those fees might be waived or reduced.  It would be in your best interest to become compliant if you have not already.

PCI DSS Version 1.2

Beginning on October 1, 2008, the PCI Security Standards Council released version 1.2 (see summary of PCI changes).  You can review the Self-Assessment Questionnaire A and Attestation of Compliance to help you get started.  Typically, Levels Two, Three, and Four Merchants will need to complete this Questionnaire.

PCI Compliancy is an Ongoing Process

Tuesday, June 19, 2007

Once you are PCI (Payment Card Industry) compliant, you should stay PCI compliant.  Usually, you rely on your electronic payment gateway (Quantum Gateway, Linkpoint, Payflow, Authorize.net/Cybersource, etc) or your IPSP (Internet payment service provider) to stay PCI compliant. This is a standard that the card associations (American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International) created to help maintain and implement the security standards of cardholder data.

Visa updates the list of processors and companies who are PCI compliant on a regular basis.  For example, Aplus.net and iTransact allowed their PCI compliancy lapse on May 31,2006 and Cybersource allowed their PCI compliancy lapse on June 30, 2006.  Aplus.net is a webhosting provider that offers e-commerce solutions.  So if you are relying on their network to be compliant, you might be liable for any breech.  Cybersource is an electronic payment gateway that is used by thousands of merchants.  Allowing their compliancy to expire, even for a few days, should be unacceptable to merchants and customers who rely on their system to securely process transactions. Of course, these companies just might be late in reporting to Visa that they are PCI compliant.

Google Checkout

Another company that has allowed their status to lapse is Google Checkout.  They allowed their PCI compliancy to expire on February 28, 2006.  Your credit card data might not be as secure as you would like to think consumers.  Even though Google is a large corporation, there is no excuse with not complying with the standards set forth by the card associations.  As with Aplus.net, iTransact, Cybersource, they might just be late in reporting their status to Visa.

Remember, it is your responsibility, as a merchant, to ensure that the provider you are using is compliant with the security standards.  If a service provider has allowed their PCI compliancy to lapse, you might consider contacting them to check on the status or switching to a provider that is compliant.

All payment gateways are required to have an on-site security audit annually and a network scan quarterly.

MasterCard and the PCI Data Security Standard

Monday, January 08, 2007

Data theft from online merchants, providers and third party processors is increasing at an alarming rate. Card associations developed the Payment Card Industry (PCI) Data Security Standard to help combat compromises. MasterCard was a primary sponsor in the PCI Data Security Standard during its inception in 2005.

MasterCard Site Data Protection

MasterCard Site Data Protection (SDP) is a component of the PCI Data Security Standard.  This program provides guidelines to merchants, acquirers, providers and compliance tools to help protect credit card data.

Being PCI Compliant

Being PCI compliant is not just getting scanned by a vendor like ControlScan. It is also adhering to standards, like storing card holder data and only allowing certain personnel access to cardholder data; completing a self-assessment questionnaire; and a possible on-site review (for Level One Merchants and Level One and Two Service Providers).

Storing Cardholder Data

Under PCI Standards, companies can store a cardholder's account number in a secure fashion. The account number should be encrypted or truncated. You can store the expiration date and cardholder's name as well. If these are stored in along with cardholder's primary account number, they should be encrypted as well. Merchants are not authorized to stored the CVC2 or Personal Identification Number (PIN).

Failure to Comply

Failure to comply with these standards can result in fines imposed by MasterCard. Level One Merchants along with Level One and Two Service Providers can be fined up to $25,000 USD per merchant or service provider.  Level Two and Three Merchants can be fined up to $5,000 USD per merchant.  Further non-compliance may also result in termination of your merchant account.