Latest news:

You are currently not logged in

Log in
Security

PCI Compliance, What is this?

PCI Compliance is just good practice.

So why do we hear so much about PCI being too hard, too costly or just too inconvenient?  Lack of understanding is one of the main issues, followed closely by being too busy with other (read “money making”) activities.  Yes, is it true that PCI Compliance does incur costs (both financial and time), but those costs are usually offset by having a more secure, more reliable and more efficient system.

 So what is PCI?

The actual name is Payment Card Industry Data Security Standard (PCI DSS).  This is often shortened to just PCI.  The following extract is from the PCI DSS website (www.pcisecuritystandards.org)
.

The PCI DSS, a set of comprehensive requirements for enhancing payment account data security, was developed by the founding payment brands of the PCI Security Standards Council, including American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Inc. International, to help facilitate the broad adoption of consistent data security measures on a global basis.

The PCI DSS is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organisations proactively protect customer account data.

The PCI Security Standards Council will enhance the PCI DSS as needed to ensure that the standard includes any new or modified requirements necessary to mitigate emerging payment security risks while continuing to foster wide-scale adoption.

Ongoing development of the standard will provide for feedback from the Advisory Board and other participating organisations. All key stakeholders are encouraged to provide input, during the creation and review of proposed additions or modifications to the PCI DSS.

The core of the PCI DSS is a group of principles and accompanying requirements, around which the specific elements of the DSS are organised:

Build and Maintain a Secure Network

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

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4:
Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6:
Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8:
Assign a unique ID to each person with computer access
Requirement 9:
Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11:
Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Now that we have the ground rules, let’s take a practical look.   Think of PCI as being the same as you turn the lights off, closing the register, turning the alarm on and locking the front door of your shop as you leave for the night – only in a virtual world and 24 hours a day. Since we never “close our web site for the night”, and it is not possible to “observe that high-risk customer”, PCI is a set of procedures and tools to assist us.

More secure, more reliable and more efficient

We mentioned a “throw away” line that PCI DSS can make your system more secure, more reliable and more efficient.  Before you brush that off as a sales pitch, let me explain.

Security  –  Pretty simple really.  PCI DSS gives you the tools to create a more secure environment in which to handle and store sensitive data.  It sets guidelines for your staff on how to handle the sensitive data, and guidelines for how to store and for how long it is to be retained.

Reliability  –  Just as simple.  With your web server being correctly monitored and supported, you won’t have as many worries about the hackers and other malicious events taking place.  Hackers usually look for “weak” sites, or “green” (ie brand new to the web) sites  – those which aren’t PCI DSS compliant or those who seem to “not care.”

Efficiency – Now that you will not be handling sensitive data, and that you have strict guidelines to follow, your staff will be more efficient.  How often have you found your staff rustling through old orders looking for a customer’s card details to make a new sale?  Now, your staff will have the knowledge that no customer data is stored, so they simply direct the customer to the website to place the order.  PCI DSS can remove time-consuming tasks from your staff.   And since your customers will be paying for the orders through your website, or your automated phone system, your staff will not have any part in the “miskeying” of card details.   We quite often hear from retailers where an order is taken over the phone, the card number is written on a small scrap of paper before being keyed into the EFTPOS machine.  Just this process alone creates 300% more possibilities of errors being created.

What if you use a Payment Gateway?

Great, you use a Payment Gateway to process cards for you.  This is a good start but does not necessarily help your PCI Compliance. PCI Compliance deals with the locations where data can be compromised – and this includes the collection point.   Let’s look at the following scenario.  You are selling widgets from your website.  You want the customer to remain on your site as they check out, so your developer has created the necessary pages under SSL to ensure the card details are transmitted safely.  Then, the Payment Gateway takes over, verifies the details with the bank and returns an authorization code to your site.  All this takes just a few seconds, and sounds secure – SSL, Payment Gateway, you never see the card details and so on.

However, you may be unwittingly putting yourself at risk.  Can you be sure that:

a)        Your web server is secure, safe from virus, malware and trojans?

b)        Your developer has created the application code correctly to ensure that your site is difficult to hack?

c)        Is your developer complying with PCI guidelines?

Knowing that your web server is safe and secure from virus, malware and trojans is an ongoing responsibility for your site.  Would you want every order placed on your system to not just be sent to your bank, but to some unknown party stealing the details in cyberspace?  Unless you can monitor and maintain your web server every day, then this is quite possible.

While SSL is an important part of the security of the transaction, it is just part of the whole process.  SSL secures the credit card details between the Customer’s browser and your web server.   And that is all it does – it does not add any other security.  So, once the Customer’s confidential card details have been delivered to your server, you need to keep it safe.   Do you know if your Web Developer has encrypted all data as soon as practical?  Do you know if your Web Developer has tested their database security for hack attempts?   Are you certain that your Developer is not writing sensitive data to a plain text log file?  Have you ever asked your Developer if they take a copy of the sensitive data for any other purpose?   If you have never asked your Developer these questions, bookmark this page and contact them now.   Then come back and keep reading!

PCI guidelines are long, detailed and open to interpretation.  Many QSAs will give different advice on the same security point.  So, when a Developer tells you that their Application (ie your website) has been tested to pass PCI guidelines, can you be sure what that exactly means?

Let’s find another Data Collection point.  If you are using the same Payment Gateway as above, selling the same products, but this time you redirect your customer to the Payment Gateway Shared Payment Page.  No longer are you collecting sensitive data?  Your PCI Compliance requirement is now just a matter of confirming with your bank that you do not collect sensitive data and that you use a Payment Gateway which is compliant.  Done, finished, you are compliant.   Now, which one would you prefer?

So, where possible, minimise your PCI Compliance requirements by outsourcing the collection of sensitive data.

But I don’t do electronic ordering – why should I read this?

Even if you do not have a fully integrated and automatic website, PCI can apply to you.   You need to ask yourself these questions:

a)        Do I take customer payments over the phone, via fax or mail?

b)        Do I charge my customers monthly for a membership?

c)        Does my EFTPOS machine print the entire card number which I then store in my filing cabinet for months?

Answering YES to these (and many others) would still make PCI Compliance a requirement for you.  The simple fact of receiving a customers’ credit card details is enough to make you liable.  So, where possible, do not handle sensitive data.

My website is too small for me to be a risk.

Really ?  The card schemes do not think so.  Even if you accept one credit card payment, then you must secure that one payment.  It is just good business practice.

PCI is too costly – I would rather just risk it.

Sure, PCI Compliance for a large company can cost tens, even hundreds of thousands of dollars.  The fines, however, for a data breach can run into the millions.  Which would you prefer – an upfront fee of thousands of dollars which gives you a more secure and efficient system, or one invoice later from your bank for millions – forcing you to close your doors.

 

A recent event.

We came across an interesting case recently.  We were contacted by American Express, as they had noticed a strange pattern in their processing.  A number of their customers had complained that their cards had been used without their knowledge.  The first thing AMEX did, in this case, was to review the Common Purchase Points (CPP).  A CPP is one or more locations where each of the stolen cards has been used.  One of our Merchants was highlighted as the CPP, so we were immediately asked to provide further information on the transaction processing flow.  In this case, we found that the Merchant was collecting the sensitive data on their site and sending it to us in the background.  The Merchant was also regularly scanning their website with a third party set of security tools and keeping their system up to date with all security patches.  It was a perfectly acceptable solution, and bank approved, solution.  However, what the Merchant did not know was that as his website took an order (which was sent to us for authorization), the details were also being emailed to the Developer for later use.  The Developer (after waiting 6 months to try to minimise the trail) started using these cards.   It took American Express 2 days to trace the fraud back to the Developer.  In this instance, the Developer was found responsible for the theft of data and dealt with.  The Merchant was fortunate that American Express ruled in their favour and allowed them to keep their Merchant Account – with the criteria that they now use our Shared Payment Page.

PCI DSS Compliance is important.  We are finding more banks are requiring even their smaller merchants show that they have considered PCI DSS, that they are getting their systems scanned and that they are aware of what the repercussions would be should a data breach occur.   PCI DSS is an important tool which we all need to address in order to keep our customers’ data secure.

About the Author

Chris Dwyer has worked in the Electronic Payments area since 1991, most recently with eMatters since 1998.  He authored a book on eCommerce Fraud titled “Selling Snake Oil at LightSpeed”, and consults to many public listed and privately owned companies on payment related issues.  

Links
https://www.pcisecuritystandards.org/index.shtml

No Comments | Be the first to comment
+-

Comment Manually

No comments