24
Jul
14

Keeping It Simple – Part 2

In Part 1, the key to keeping things as simple as possible is to avoid any storage of cardholder data.  Period.  End of discussion.

I also covered mobile payments because more and more small merchants go to those solutions because of the cheap interchange fees on transactions.  However, few small merchants truly understand the risks that these solutions present because they are offered by seemingly trustworthy providers.

So what else can you do to keep things simple?

Outsource

When consultants typically mention outsourcing, huge amounts of money typically float past people’s eyes.  However, PayPal is outsourcing and its fees are not too bad.  There are a number of similar services for eCommerce out there for conducting payments.  There used to be concerns about abandoned shopping carts because of a separate Window pop up, but as online shoppers have gotten used to PayPal like services, that has diminished.

Your bank may also have a partnership with one or more payment vendors, so it is worth it to talk to them first to find out what options they may have to offer.  If they do partner with a payment solution, a lot of times they can offer reduced fees/expenses and other incentives to use their partner(s).

The key thing to understand is that even when you invoke PayPal or similar services from your Web site, you still have a responsibility to ensure the security of your Web site.  This is because your Web site is the system that directs your customer to the payment service you have chosen.  If an attacker changes that redirect to “The Guru’s Payment Process”, that is not PayPal’s problem, that is your problem.  This was clarified in the PCI SSC’s Information Supplement on eCommerce back in January 2013 when the Council declared that even Web sites that redirected to a payment service still were in scope, albeit a very reduced scope.  The ramifications of this supplement have been discussed repeatedly with QSAs since then, but in my experience that message is still not being consistently presented to QSAs’ customers.

No Choice But To Store Cardholder Data

So you have found a solution that does exactly what your business needs, but it stores cardholder data (CHD).  The first question you should ask the vendor is, “How does your solution secure the stored cardholder data?”

For vendors that use data encryption, the answer to this question should be either triple DES (3DES) 168-bit or advanced encryption standard (AES) 128-, 192- or 256-bit encryption.  DES and 3DES 56- and 112-bit are no longer considered secure, so any vendor using those is not meeting the PCI encryption requirements.  Anything else and you should consult with a QSA as to whether or not the encryption algorithm is acceptable.

For vendors using encryption, the next question you should ask them is, “How does your solution perform key management?”  Preferably, someone other than someone in your organization manages the encryption keys such as the vendor.  However, I have seen some solutions where the key management is done by the merchant through a sophisticated key generation solution in the application so that the merchant never actually knows or has access to the encryption key(s).  The questions you need answered are all in requirements 3.5 and 3.6 of the PCI DSS.  If the vendor cannot address these requirements, then you need to find a new solution vendor that can provide answers.

For vendors that use one-way hashing, the preferred algorithms used should be SHA-2 or SHA-3 with a salt value.  MD5 and SHA-0 have known security issues that make them no longer secure.  SHA-1 has a potential security issue that could cause data to also be insecure, but a lot of software vendors still use SHA-1 with a salt value.  If you are going to use a solution that relies on SHA-1, the vendor should have additional controls in place to monitor access to the data and alert on any access where the data is being accessed in bulk.  If not, find another vendor.

Tokenization

Do not give up hope if your preferred solution stores cardholder data (CHD).  You may be able to use a processor that tokenizes the PAN.  Once tokenized, the PAN is no longer considered CHD, so the solution would not being storing CHD.

Proper tokenization is a form of encryption or hashing in that the token does not have any true one-to-one relationship with the PAN it replaces.  However, this is a fact you need to confirm with the transaction processor to ensure that their tokenization process is secure.  If they are not representing their token as secure, you need to move on to another processor.

Tokenization can occur at the swipe/dip of the card at the point of interaction (POI) or as the byproduct of the successful completion of a transaction (the most common occurrence).

Tokens can also be generated for eWallet situations where you want to encourage customers to come back and shop at your eCommerce site and store their cardholder information for ease of subsequent transactions.  In these instances, the processor generating the token also stores the CHD and then translates the token to that stored CHD when your system submits it and then sends the CHD for approval for payment.

This is how ExxonMobil Speedpass and open road toll collection systems work.  The RFID device is the token and the payment system recognizes the serial number of the RFID device and translates that to the customer’s stored CHD for payment processing.

There are more than enough ideas presented in these two posts to vastly simplify any merchant’s PCI compliance exposure.  If these solutions will not solve your issues, then you are either making your business too complex or your business model truly needs some expert advice to address your compliance challenges.

About these ads

16 Responses to “Keeping It Simple – Part 2”


  1. July 27, 2014 at 5:12 AM

    I did a 10 minute presentation to an audience of small business owners last week about PCI DSS, I asked the question how many of them had heard of PCI DSS, only 1 hand went up out of 45 attendees.

    • July 27, 2014 at 5:27 AM

      Surprising as you would think the word has truly gotten out. Thanks for sharing this insight.

  2. July 25, 2014 at 3:50 PM

    Your time and efforts are very much appreciated!

    In reference to a statement in the Outsource paragraph above regarding web redirects and securing a website, you noted “The ramifications of this supplement have been discussed repeatedly with QSAs since then, but in my experience that message is still not being consistently presented to QSAs’ customers.”

    I was in a discussion with a QSA regarding web redirect servers and authentication servers recently– This QSA was representing a third party vendor we had contracted with a few years ago– this QSA made the statement “that it’s all based on interpretation and my institution couldn’t expect third party vendors to change their processes because of one line in the standard (referring to the PCI Scope paragraph on page 10 below)”.

    It’s frustrating when QSA’s disagree and I would look to the PCI SSC for further training and clarification on “Interpretation” and “it depends on your appetite for risk”. I am thankful we have contracted with a QSA firm that is on the conservative side and does not “interpret” the standards based on appetite for risk, but rather on the standards and reporting instructions. It’s been a difficult process educating our Service Providers to our level of due diligence, and we have changed vendors in some instances.

    Thank you for your posts! I always learn something!

    Best,

    Page 10, PCI DSS:
    “The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.
    Examples of system components include but are not limited to the following:
     Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE”.

    • July 26, 2014 at 7:27 AM

      Just as a client’s personnel cannot agree on what level of risk to accept, every QSA Company (QSAC) and even QSAs within a given QSAC have differing levels of risk acceptance which is where the problem lies. That is human nature in action and I’m not sure how the Council or anyone else is going to take that out of the process.

      Right now we are working on scoping using the Open PCI Scoping Toolkit as a framework. I can tell you that there have been some interesting and, at times, heated discussions about the risks presented by allowing certain systems to access others. Our discussions are heated because each of us has differing risk tolerance levels. It is likely going to take us a while to work through this and come up with something workable. However, this is why the Scoping SIG collapsed a number of years ago.

      That said, QSAs need to do a better job explaining WHY they are recommending certain scope, solutions, etc. based on a discussion of risk. That is how I present issues to my clients. So I might provide three different solutions – one requiring a high tolerance of risk, and two with varying moderate levels of risk and then let the client decide what they are willing to accept. All will be PCI compliant, but some may have additional controls to be implemented and monitored above and beyond the basic controls required to be compliant.

      This is the problem any organization faces with security and privacy discussions. Everyone has their own opinion of risk and how much risk they are willing to accept. Until everyone can come close on that discussion, then you will continue to see what you see.

      • July 26, 2014 at 8:16 AM

        Thanks! We also utilize the Open PCI Scoping Toolkit as a framework– and yes we’ve had heated discussions as well. Thanks again.

  3. 6 Brett
    July 25, 2014 at 8:04 AM

    Ahhh, web redirection scoping. At first scoping was fuzzy and left to be interpreted by the QSA for Level 1 Merchants. Then the “clarifying” scoping statements came out for SAQ users, giving non-Level 1 Merchants “a way out” by utilizing a fully outsource hosted payment page. (even though you and I know this does nothing for the protection of the actual redirecting server). :)

    Long story short, QSAs are now reluctant to confirm scoping guidance around web redirection servers for Level 1 Merchants, hoping they can offer their clients a way out IF the above mentioned “clarifying” statements, can and ever will apply to Level 1 Merchants.

    The SSC has been aggravatingly very quiet around this since releasing their SAQ guidance back in March. (probably because they know it doesn’t do anything to protect the underlying issue).

    Unfortunately looks like I’m going to have to wait for the PCI Community Meeting in Sept, to corner the Council in providing clarity for Level 1 Merchants. At this point, I don’t care what the SSC says about web redirection servers, I know what the point of protecting the redirecting servers is for and understand as such. The problem is, our budget people won’t provide funds for a build out because we have no official requirements to do so.

    I’ve read what the Guru has said on this, however we don’t have the Guru as a QSA. So, kinda stuck here.

    • July 26, 2014 at 7:16 AM

      This topic was actually discussed at last year’s Community Meeting in the QSA session before the public meetings. The Council chastised the QSAs for not doing more regarding the eCommerce information supplement and redirects. However, as a number of us pointed out to the Council, QSAs are loath to go out on a limb without discussion and clear guidance from the Council which was why a lot of us dragged our heels in doing something. As a result, we went back and developed a position paper on the topic and share that with clients and prospective clients to explain this topic.

  4. 8 Utah_Man
    July 25, 2014 at 7:42 AM

    Thank you for the information! So, just how much does encryption limit scope? Our CISO believes that the 3DES encryption method our machines are using is not secure enough. We are upgrading our remote locations with firewalls and VPNs directed to a PCI environment. Obviously, it is a secure method, but do you think that is necessary seeings how our swipe machines encrypt the data and we do not have access to the keys?

    • July 26, 2014 at 7:12 AM

      See my post on encryption and scope – http://pciguru.wordpress.com/2013/03/07/encrypted-cardholder-data-out-of-scope/

      As to your CISO being concerned about 3DES, that is a valid concern. 3DES 168-bit is the only form left that has not been broken and NIST keeps warning that it is just a matter of time before that form is also cracked. Granted they have been warning about this for around the last 10+ years. But with the computing capabilities of the cloud, it’s possible that their warnings should be heeded.

      As a result, a lot of vendors of terminals and secure transaction communications are heading to the advanced encryption standard (AES) for their encryption solutions.

      • 10 Andrew Jamieson
        July 27, 2014 at 8:20 PM

        Triple DES is fine for payments. Every PIN you have ever entered into any device has been encrypted with TDES, using a 112 bit key. If you have 2^40 plaintext/ciphertext pairs, you can reduce the operations required to break this down to 2^40, but this has never been practically demonstrated _anywhere_ and is impractical for payment messaging anyway. I would be much more concerned about your PKI implementation, key and certificate management, and advances in factorisation that are making RSA less and less secure. Until the new version of ISO9564 is ratified, we _cannot_ use AES for PINs, and doing so will require changes to messaging formats like ISO8583 anyway.

      • July 28, 2014 at 4:14 AM

        Thank you for the clarification.

        I was thinking of 3DES when used to encrypt telecommunications, not PIN blocks.

      • 12 Andrew Jamieson
        July 28, 2014 at 7:52 PM

        Still OK for messaging in payments, not just PINs. Much more likely that problems will be found in your PKI or key management than TDES is broken.

      • July 29, 2014 at 1:07 PM

        Oh ye of little faith. LOL!

        A PKI implementation messed up? Highly likely.

  5. July 24, 2014 at 9:20 AM

    Great part 2. Thanks for taking the time to write this informative articles.

  6. 15 Derwent
    July 24, 2014 at 7:08 AM

    As an ex-Security Manager in a previous career I understand all of this. Now as a small independent retailer with some web sales, it is all TOO MUCH! sorry to shout :-)

    75% of business in the UK is small business. We just want a solution provided to us along with the card processing package. We don’t want to be that solution!

    The card payment part of running a business is just one tiny part of our very busy lives, for the PCI people it is a daily job, they don’t seem to understand retailers are not that excited about being bossed around, blamed, responsible, a risk etc. We just want to take cards in the same way our customers use cards. If its all so difficult its a pity the card companies don’t own up to the public and give up.

    I love this site and do take it seriously – honest! But I suspect my thoughts above are how most small businesses really feel. Just waiting for someone clever to come along and offer an alternative.

    • July 26, 2014 at 7:06 AM

      PCI is unfortunately required because, unlike you, merchants large and small, were NOT diligent in ensuring that payments were performed securely.

      If you use a terminal such as Verifone or Ingenico either through a phone line or 3G/4G cellular, you should be fine and PCI compliance should not be a problem. Same with outsourcing eCommerce to Amazon, eBay or similar merchant sites can significantly reduce scope and improve security if implemented properly.

      I agree that the current card paradigm is broken and we need to come up with a new one. However, Visa and MasterCard need to recoup their investment in EMV and so until that happens, we will stay the course.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

July 2014
M T W T F S S
« Jun   Aug »
 123456
78910111213
14151617181920
21222324252627
28293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,018 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,018 other followers

%d bloggers like this: