Developers Beware – Stripe

A reader pointed out this merchant services provider to me, so I checked it out.  I ran into some concerns as I reviewed their documentation that I want to share with you all so that you have a better understanding of what Stripe does and provides.

The first thing that I want to point out is why you need to carefully read a service provider’s Web site and understand what is what.  If you look at the Stripe General Questions page there is a discussion of PCI compliance.  Stripe states that they are a PCI certified Level 1 service provider.  What that means is that Stripe’s backend processing of card payments is PCI compliant.  This statement has nothing to do with their Javascript program or any other services that Stripe offers.

But, you say, Stripe provides a Javascript program for processing payments.  What about its PCI compliance?  Good question.  Here is a gray area with PA-DSS compliance of applications.  Because Stripe is not technically selling its Javascript file (it is provided free), I am sure they believe that the Javascript does not have to be certified.  However, the General Questions page is very clear that “Use Stripe.js as the only means by which you accept payment information and transmit it directly to Stripe’s servers.”  To me I would think the required use of the program would imply that the Javascript is required to be PA-DSS certified since developers have no choice but to use it.

That brings up how is Stripe’s Javascript maintained?  What ensures that someone does not change the script and now it starts securely communicating with another server as well as Stripe’s?  This is why PA-DSS certification is necessary for applications because there is too much risk if those applications are not properly maintained and controlled.  All it takes is a single successful attack and every one of Stripe’s customers will pick up a new Javascript that will do whatever the attacker desires.

The next concern I have regarding Stripe is their statement that by using their process, “you completely avoid handling sensitive card data, and keep your systems out of PCI scope.”  Wait a minute.  Stripe states just above that that you need to, “Serve your payment page over SSL.”  That implies that their Javascript runs on your server.  This gets confirmed on their SSL page where they state that their Javascript only communicates with their backend servers over an SSL connection.  It may be their code, but it is executing on your server and that means that your server is in-scope for PCI compliance.

The PCI SSC really needs to get on top of service providers and their claims.  It troubles me that this service provider is making claims that are totally incorrect.  It is these sorts of claims that get good people get into trouble.  Most developers and their organizations do not have the necessary detailed understanding of the PCI standards and therefore trust service providers to be the experts which, in the case of Stripe, they are obviously not experts and are just as clueless.

Advertisement

Remembering Walt Conway

It is with deep regret that I report the passing of my friend, Walt Conway, on Tuesday, June 26, 2013.

Walt and I met at the first PCI Community Meeting in Toronto back in the fall of 2007.  We both attended the infamous card brand session on pre-authorization data at that meeting.  We bantered back and forth periodically about what were the ‘take aways’ from that session.  For the record, I do not think we never completely agreed on our interpretations of the ‘take aways’.  However we did agree that pre-authorization data was to be protected just the same as post-authorization data.

Over the years Walt would contact me about mistakes, misinterpretations or misunderstandings regarding postings.  A number of times, I sent Walt the posting and he would edit it so that he felt it better represented the PCI SSC’s interpretation.  I always appreciated his help in that regard because the point of this blog is to provide people with accurate information.

Walt took over as the PCI commentator at StoreFrontBackTalk after the sudden passing of David Taylor a number of years back.  I always enjoyed Walt’s columns and that is why I posted the link on my blog to StoreFrontBackTalk.  While a number of times we covered the same topics, I always appreciated Walt’s take on those same topics.

Walt’s family has requested that donations be made to the Walter T. Conway, Jr. Fund at Episcopal Community Services.  You can make a donation either on-line at http://www.ecs-sf.org or by mail at Episcopal Community Services, 165 Eighth Street, 3rd Floor, San Francisco, CA 94103 to the Skills Center/CHEFS program.

Rest in peace my friend.  I will miss you.

I Am Concerned – Linkables

I got notified of a new service that is popping up at merchants these days, particularly grocery chains.  The service is called Linkables (mylinkables.com) from Linkable Networks, Inc.  The issue I discovered with this service is not PCI related, but it is privacy related.  With all of the discussion going on regarding the NSA collecting and analyzing telephone records, I think this is a good venue to make people aware of a practice that is possibly even more risky than storing PANs.

According the their Web site:

“Linkables are savings offers that can be connected to your credit or debit card to deliver savings to you automatically after you shop. It’s a simple and convenient way to take advantage of advertisers’ online and offline promotions, with no coupons to clip and no paperwork after you shop. Offers can be used online and offline just by using your credit or debit card.”

When you go to the Linkables Web site, you set up an account using an electronic mail address and a password as is standard operating procedure these days.  But where this service goes terribly wrong is in the registering the subscriber’s credit/debit card(s).  While you are required to provide your PAN and expiration date, the subscriber is then required to provide their logon identifier and password to the online banking system for the bank that issued the card.

Yes, you read that right.  The customer needs to provide access to their online banking system.  The reason given on the Linkables’ FAQ is:

“To deliver your savings, MyLinkables needs to be able to see when you redeem offers. To identify your redemption transactions in a secure way, MyLinkables prompts you to enter your card number and expiration date, and in some cases, your online banking credentials. This is to establish a secure connection for ongoing read-only access, and for the ability to credit your account with your savings. This connection is sustained via a PCI-compliant secure token. For some banks, we are able to create this connection without asking you to enter this information.”

The first problem I have with this is that Linkables invokes PCI compliance as though it should provide some sort of comfort to their customer.  However, PCI compliance has nothing to do with access to someone’s bank account.  They have a green colored seal at the bottom of their home page that indicates they are a “Payment Card Industry Data Security Standard PCI Level 1” which is meaningless on a variety of levels.  If you read the FAQ, PCI compliance is brought up all over the place for not only securing cardholder data, but for implying Linkables is secure as a whole because of their PCI compliance.

But an even more troubling discussion is in regards to the fact that in order to provide you your rebates, they need access to an online banking account.

To give customers a better sense of security, the following FAQ answer is given in regards to if someone does manage to compromise Linkables and obtain customer online banking login information.

“No, MyLinkables encrypts your card number and expiration date, and does not store your bank account credentials. The identifier that was created when you entered your account credentials is encrypted, never displayed within MyLinkables, and connects to your account exclusively with read-only access to view your completed transactions. In addition, details about your banking transactions are not stored in MyLinkables.”

You might want to read that response multiple times as it makes no sense.  In the first sentence they claim they do not store the credentials, then in the second sentence it appears to imply that the credentials are stored but encrypted.  But the real troubling statement is that somehow Linkables only gains read-only access to the customers’ bank accounts.  I have audited a lot of online banking environments over the years and I have never run across one that had read-only access.  Last I knew my online banking credentials gave me full access to my accounts.  So how Linkables ensures that they only have read-only access must be in the fact that their software only reads information.

The bottom line on this service is that either this is the biggest, legitimate looking scam to obtain access to peoples’ bank accounts through their online banking system OR this system was developed by people that had no clue as to how the financial systems in the world operate.  I am hoping it was the latter, but I really have to wonder based on the FAQ answers.

The PCI SSC and the card brands should be concerned about this service’s abuse of the PCI standards.

Update:  I got the following response today from Linkables regarding the question I put to them regarding why online banking credentials are required.

“We’ve partnered and integrated with Visa and MasterCard.  When you register a Visa or MasterCard, only the 16-digit card number and expiration date is required.  

We’ve not yet completed our integration with the AMEX and Discover card networks, however.  Until then, cards must be registered via Yodlee, our PCI-Compliant processing partner.  Yodlee then communicates with the card-issuing bank and is issued their own token for use in receiving read-only transactional data from the bank.  We don’t have any access to initiate any new transaction of any type.”

While I get this, I still do not understand what the bank has to do with anything.  They state that they need transactional data from the bank, yet the customer’s bank would not have transactional detail other than a total transaction amount.  As I understand it, Linkables is refunding like a coupon.  So they need to know you purchased ABC Orange Juice for example so that they can rebate $1USD to your account.  That detail comes from the merchant that sold the orange juice, not the bank.  The mystery about this service just gets worse, not better.

Diagramming For Your QSA

I have been reviewing network and data flow diagrams for PCI compliance engagements for years.  But it only recently dawned on me that I have never discussed the issues that keep recurring when I review organizations’ network and data flow diagrams as part of the PCI compliance efforts.  To rectify that situation, here are some comments so that all of you can provide better diagrams to your QSAs.

Network Diagrams

Some organizations treat their network diagrams better than some governments treat their Ultra Top Secret documents.  Even though all organizations require a non-disclosure agreement (NDA) to be in place before having a QSAC conduct their PCI assessment, we constantly run into networking and security personnel that keep detailed network diagrams secret from the QSA.

Unfortunately for these people, the PCI assessment process requires a level of detail that is not comfortable.  In such situations I have received diagrams from network/security personnel that can only be described at levels higher than even high level diagrams.  Such documentation is worthless to a QSA and only puts thoughts in the back of the QSA’s mind regarding what you are trying to hide.

QSAs need diagrams that show everything that is contained in the cardholder data environment (CDE) and all of the network connections to the CDE.  A QSA needs this level of detail to reconcile your configuration standards, running configurations and other relevant documentation to the network diagram as part of the process to ensure that the CDE is properly defined and securely configured.  The network diagrams are also used by the QSA to ensure that appropriate samples are taken for devices in-scope for the assessment if sampling is used.

At a minimum, the information that needs to be on network diagrams includes all virtual local area network (VLAN) numbers (if applicable), IP address ranges/blocks for relevant network segments and key firewalls, routers, switches and servers along with their DNS names and IP addresses.  Anything less just makes the PCI assessment process all the more difficult for you and your QSA.

Data Flow Diagrams

Data flow diagrams typically end up in the Details About Reviewed Environment section at the front of the ROC.  As a result, you need to make sure that they carry enough detail for readers of the ROC, but not enough detail to aid an attacker if they get a hold of the ROC.  I will talk about the details that are required in these diagrams in the next section on ROC Diagrams.

The first thing that gets noticed with data flow diagrams is that they do not even come close to matching up to the network diagrams.  This is typically because the data flow diagrams are prepared by the business owners of the card processing processes and these people typically have no idea how the data actually flows through the network.  As a result, the QSA has no point of reference between the data flow and the network to evaluate whether the CDE is properly defined.  As such, the first recommendation I make is for the business owners and the networking people sit down together and get their diagrams in synch.  Not that the same detail that is in the network diagrams needs to be in the data flow diagrams, but key security points such as firewalls, servers, public networks and business partners should be noted in these diagrams.

The second thing that I notice in data flow diagrams is that there can be a lot of lines with arrows, sometimes even colored in red, green, yellow and other colors.  But most of the time there is no description or legend that allows the reader to understand what the diagram is to represent.  Worse yet, the lines and arrows are all over the place and difficult, if not impossible, to follow in a cacophony of color or monochrome.  To add to this mess, sometimes we get this overlaid on top of the detailed network diagrams in an effort to address my first point.  The net result is that it is all clear as mud!

And if you want to add insult to injury, you do get some commentary with the data flow diagrams in the addition of callouts or balloon comments.  Unfortunately, these comments are near to impossible to understand what comments/balloons go with what line.  Or if that comment/balloon is also a data flow line.  Yuck!

What typically needs to be done is to create separate diagrams for how a transaction flows when a card is processed.  This could result in multiple diagrams for “brick and mortar” retail locations, eCommerce, call center, returns and other order processing processes.  Then a diagram that shows the data flow for settlement.  Settlement may result in multiple diagrams as well.  Then there may be other data flow diagrams that show other manual or paper-based processes related to CHD that also need to be documented.

ROC Diagrams

In the Executive Summary and Details About Reviewed Environment sections of the front part of the ROC, the QSA is required to provide three diagrams.

• A “high level” network diagram.
• CDE external and internal network connectivity diagram.
• Card transaction data flow diagram.

The purpose of these diagrams is to give people such as those at your acquiring bank, the card brands, or heaven forbid, the forensic examiners in the event of a breach, an overview of your organization’s network and how cardholder data flows over that network so that they have some context.

The high level network diagram needs to include the following information.

• All connections into and out of the network, including demarcation points between the CDE and all other networks/zones.
• All critical components and key systems, as well as their locations and the boundaries between them.  You do not have to document every switch crossed in the network, but you need to show the key components such as core switches or other networking devices that impact the security of the CDE. You also need to document some of the key servers such as Active Directory, SIEM, patch management, backup, operations management or other operational servers that might not be in the CDE but provide support to the CDE.
• All other necessary components or key systems, their locations and boundaries, as applicable. This would be devices such as consoles and monitoring stations as well as any user systems that have access to the CDE or to the operational support systems.

Note that there is no requirement to provide details such as DNS names, IP addresses or other identifying information that would be extremely useful for an attacker.  There needs to be sufficient detail as to provide the reader with a reasonable understanding of the architecture of the network so that they can assess whether the ROC covers everything it should cover and that the CDE was properly defined.

The CDE external and internal network connectivity diagram needs to provide the following information.

• All boundaries of the cardholder data environment.
• Any network segmentation points which are used to reduce scope of the assessment.
• Boundaries between trusted and untrusted networks.
• Wireless and wired networks.
• All other connection points applicable to the assessment.

Again, there is not a lot of detail provided here, but enough information to give the reader the context of what is connected to what and how the CDE is structure for security.

Data flow diagrams need to provide the following.

• Identify all transmission and processing flows of cardholder data (CHD) including: authorization, capture, settlement, chargeback and any other CHD applicable data flows.
• For each transmission and processing flow: describe how cardholder data is transmitted and/or processed and identify the types of CHD involved (for example, full track, PAN, expiry date).

As I stated earlier, for all of these diagrams, you may need to create multiple diagrams to get your meaning across.  So do not try to pack too much information into a single drawing only to have it unreadable in the ROC.

These ROC diagrams are typically a collaborative effort between the QSA and the appropriate personnel in the organization.  In some cases, it can take quite a lot of work and creativity to get diagrams that are useful yet does not give away the store.

Hopefully you now understand what diagrams your QSA needs and the level of details required.