New PCI Compliance Rules Effective Janiary 1 2015

Hi, we’ve changed the format of our Security Newsletter to provide a little more depth on specific Security Issues that are current and may impact your business.   We hope that you like the change.  This week we’re talking about the new Security and Reporting Requirement of PCI for those organizations that process credit/debit cards.  If you aren’t up-to-date on the recent PCI changes please read on . . .

PCI 3.0 Security and Reporting Requirements just got tougher!

Beginning January 1, 2015, the new Payment Card Industry Data Security Standard 3.0 (PCI DSS 3.0) went into effect.  It contains significant changes that will require businesses to do more to tighten credit card processing security, and many may not realize it.  The DSS 3.0 standard imposes increased security requirements for all organizations that process credit cards or use third parties to perform that function for them.  If you haven’t begun working on compliance with that standard, you should start immediately.

Here are several common misconceptions about PCI compliance and reporting:

1. Outsourcing card processing makes us compliant – Wrong!
   
   
   Outsourcing simplifies payment card processing but does not provide automatic compliance.  Both the process AND you must complete security assessments and file reports. 


2. PCI compliance is an IT project – Wrong again!
   
   
   PCI compliance is a business issue that is best addressed by a multi-disciplinary team. The risks of compromise are financial and reputational, so they affect the whole organization.  Some aspects of PCI compliance are technical but many more are procedural.  


3. We don’t take enough credit cards to be covered by PCI.  - Not So!
   
   
   PCI compliance is required for any business that accepts payment cards – even if it is just one, you must comply.

Frequently asked questions about PCI 3.0:

Can I transition my PA-DSS v2.0 application to v3.0?

All payment applications will need to undergo a full PA-DSS v3.0 assessment in order for it to be considered fully validated so the answer is no.

Am I still required to report even if I outsource my Credit Card Transactions?

In version 2.0 of the PCI DSS, if merchants fully outsourced their e-commerce payments, their web environment was out of scope for the standard – meaning they did not need to go through the compliance process for their e-commerce website.   However, under the PCI DSS 3.0, most merchants will be faced with more than one hundred security controls that include firewalls, vulnerability scanning, penetration testing and more.

Here are some of the KEY requirements of PCI 3.0 that are now in effect:

1. Merchants must Install and maintain a firewall configuration to protect cardholder data.


2. You must Encrypt transmission of cardholder data across open, public networks.


3. Restrict access to cardholder data by business need-to-know.


4. Assign a unique ID to each person with computer access (think Login ID’s and passwords)


5. Restrict physical access to cardholder data.


6. Track and monitor all access to network resources and cardholder data.


7. Regularly test your security systems and processes.


8. Maintain a policy that addresses information security.

Failure to meet these requirements may result in fines or termination of credit card processing privileges.

Another key consideration is responsibility when something goes wrong.  In the past, the credit card companies were likely to take the financial hit on a fraudulent transaction.  Now, that responsibility could fall directly to you if you haven’t maintained full compliance.

On April 15, 2015, the PCI Security Standards Council also released PCI DSS version 3.1. 

Here's what you need to know about this update:

PCI DSS 3.1 updates key requirements addressing insecure SSL and early TSL protocols:

• By June 30, 2016, merchants cannot use SSL and early TSL protocols as standalone security controls for payment data.  If you’re unsure if your web-site is using any of these protocols, you should contact your web author immediately and get ready to pull them out of your credit card processing system.


• Merchants should immediately cease using the SSL and/or early TSL protocols in any new implementations.

What then is the merchant to do?
-- First, have a good set of policies and well-documented business practices. Also encrypt or otherwise protect all of your credit card data (if the entire card number is stored).

-- Second, have those policies and practices reviewed on a periodic basis (annually at a minimum) by one or more experts in the field. These include law, privacy and security experts.

-- Finally, question yourself over retention. Is the risk and cost of retention worth the benefits of having the data on hand?

-- Some merchants have been entirely too lax when it comes to in-house security. 

-- If you’re one of those organizations that lets employees share Login ID and/or password, those days must come to an end or you could lose the rights to accept credit or debit cards in your business.

We hope that you find this information useful.  If all of this mystifies you, you’re not alone but you can call ACT for help with insuring that your business is compliant with these new standards.

If you have any security questions that you’d like answered, please send us an e-mail and we’ll include the answer in our next Security Round-up.

Thank,

Jeff and your friends at ACT.