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:
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.
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.
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:
Merchants must Install and maintain a firewall
configuration to protect cardholder data.
You must Encrypt transmission of cardholder data
across open, public networks.
Restrict access to cardholder data by business
need-to-know.
Assign a unique ID to each person with computer
access (think Login ID’s and passwords)
Restrict physical access to cardholder data.
Track and monitor all access to network
resources and cardholder data.
Regularly test your security systems and
processes.
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.