NetSPI Blog

What Happens When a Merchant Outsources Their e-Commerce Environment? Part I

David Gianna | Monday, April 5th, 2010

Many brick-and-mortar merchants maintain some type of e-commerce environment. For those of you experienced in management of PCI, this has obvious implications: assessment of infrastructure, firewalls, web servers, server administration, access controls, cardholder data encryption, storage, retention and transmission, database administration and management procedures, web application development processes, logging/auditing, file integrity monitoring, and physical security of the hosted environment – and that’s just what applies directly to the e-commerce environment. A full PCI assessment of the organization would include significantly more, and would be subject to the architecture and the specific nature of that organization’s business models. Basically, that’s a mouthful for saying that e-commerce would require a lot of work during a PCI assessment.

Some organizations that operate an e-commerce environment might find that it is a significant chunk of their business compared with their retail operations. Others find that it’s a very small part. A brick-and-mortar retailer that sells gift cards on the web is an e-commerce retailer, even if this amounts to less than 1% of their revenue. In my travels, I’ve run across this model of e-commerce operations quite often. In other experiences, I’ve seen the opposite extreme – a mixed retailer that derives a significant portion of their revenue from e-commerce operations such as direct fulfillment, store pickup and personal shopper services. In all cases, the responsibility for protecting cardholder data in the e-commerce environment is the same – and frequently utilizes the same or similar technologies, regardless of scale.

Given the amount of attention that e-commerce operations draw during a PCI assessment (which is not in any way meant to detract from the amount of attention drawn to retail POS systems, back office operations and ancillary systems), it is no wonder that there is lots of conversation around the outsourcing of the e-commerce environment. Like anything else treated by PCI DSS – the workload is dramatically reduced through the reduction in scope. Take e-commerce out of scope, and the organization’s PCI DSS program is free to focus on other areas of compliance.

But what parts of an e-commerce environment may be taken out of scope? And is it possible to take the entire e-commerce environment out of scope? The answer is both: “It depends” and “It varies” just as surely as e-commerce environments themselves both depend and vary according to their architecture. But before we can tackle this, let’s be sure that we understand what an e-commerce environment actually is.

We are all familiar with the large e-tailer environment – the ones with the popular web pages that have categories upon categories of items for sales, shopping carts and secure transaction pages for placing orders. We also touched on the retail sites that allow you to purchase gift cards, or to order merchandise or to pre-order items for in-store fulfillment. Clearly, these are also e-commerce operations. In all of these cases, a website at some point completes a purchase by collecting cardholder data from a buyer and then enters order information into some type of an order fulfillment or an order management system. This much is clear. What is also clear is what most often is NOT an e-commerce site: Any site that does not prompt for payment, and doesn’t allow you to purchase anything. There may be catalog items, and pricing information, even product availability information that lets you look up store stock in real-time – but the site never handles any cardholder data. Lots of content and pretty pictures, perhaps flashy videos, but no cardholder data. No, not within scope of PCI. But what about the web site that has a combination of both? It has all of the flash, the ads, the interactive product guides and also allows for you to purchase items – right from your browser. Definitely an e-commerce site and definitely in scope for PCI? Right? Once again, the answer is “It depends” and “It varies.”

In the next blog post, we will examine the implications of distributing these systems across multiple architectures, and the impact that outsourcing some or all of this will have on the PCI scope.

See you then!

Permalink | Email the Author | Subscribe to PCI/PS-DSS Blog

Common Compliance Hurdles Part 1: Increased PCI Scope

Ryan Wakeham | Tuesday, March 30th, 2010

Looking over the findings of the last few dozen PCI gap assessments that NetSPI has performed, I am struck by the fact that today, well into version 1.2 of the Payment Card Industry Data Security Standard (PCI DSS, or just DSS), one of our most common findings remains increased scope due to lack of network segmentation.  For example, we have seen numerous merchants with relatively simple payment processing environments that have a very large and complicated PCI scope and must bear the associated costs (e.g., develop and apply hardened system configurations, pay for external scanning services, etc.).  In some cases, the merchant may not even have a real business need to store cardholder data (i.e. they could simplify their business processes and complete a Self Assessment Questionnaire C rather than the much longer SAQ D) but, even if they do, the scope of compliance is often far larger than necessary.  Limiting the scope of the systems that are required to meet PCI DSS compliance gives merchants and service providers the best “bang for their buck” in terms of reaching their compliance goals, yet it seems that many merchants struggle with defining and implementing the controls necessary to do just this. 

The first step in reducing the PCI scope through segmentation is to determine exactly which systems store, process, or transmit cardholder data.  While this may be very straightforward for some organizations, it may be helpful to create a cardholder data flow diagram for more complex environments.  Once cardholder data systems have been identified, a process of isolation and segmentation can begin.  Ideally, cardholder data systems should be segregated off in a “PCI island” by a stateful firewall; Internet-facing systems should be placed in a separate DMZ segment.  Once these major changes have occurred, locking down and documenting the firewall ruleset, implementing the necessary management processes, and other items detailed in Requirement 1 are much easier to address.

Though this process may look simple on paper, it can often involve the rearchitecture of not just the network but also individual systems, as PCI-related applications and functions should be isolated from other business functions (e.g., a database containing a parts inventory along with invoicing and payment information should be separated into individual databases in isolated network zones).  However, through proper segmentation, merchants and service providers can significantly reduce the cost and scope of compliance and need only apply the DSS to systems and devices that store, process, or transmit PCI data.

Permalink | Email the Author | Subscribe to PCI/PS-DSS Blog

Brand Reciprocity Revoked by Visa and MasterCard: What It Means for Merchants

Lee Buttke | Thursday, November 12th, 2009

Brand reciprocity refers to how the card brands acknowledge the different merchant levels of the other card brands. For example, if an organization is a Level 2 Visa merchant but a Level 4 MasterCard merchant (both designations based upon transaction volume), brand reciprocity means that the merchant would be classified as a Level 2 merchant.

The classification level determines the type of validation required (SAQ or ROC). Of the other participating card brands, only Discover acknowledges brand reciprocity; AMEX and JCB do not. However, Visa Canada still recognizes brand reciprocity within merchant levels.

Brand reciprocity gained increased importance this past summer, when MasterCard announced that Level 2 merchants would have to validate compliance through an onsite audit and a ROC done by a QSA. The announcement specified that Level 2 MasterCard merchants would have to validate compliance through this more rigorous process by the end of 2010. Under brand reciprocity, this requirement meant that if a merchant was, say, a Level 2 Visa merchant (previously validating compliance through a SAQ) and a Level 3 MasterCard merchant by volume of transactions, the merchant would be considered a Level 2 MasterCard merchant and would thus be required to validate compliance through a ROC by an outside QSA firm.

With brand reciprocity revoked, we need to take a look at a merchant’s transactions by card brand. By looking at these individual card brand transaction volumes, we can assist the merchant in making a determination of its merchant level status and the corresponding type of validation required. Also, remember that brand reciprocity is still in effect for Visa Canada.

Permalink | Email the Author | Subscribe to PCI/PS-DSS Blog

Questions on PA-DSS from Software Companies and Straight Answers

Alex Crittenden | Thursday, November 5th, 2009

This post is a result of many, many conversations with software companies regarding the PCI Payment Application Data Security Standard (PA-DSS).  What’s really interesting about all those conversations is that they tend to fit into two categories – the first involves software companies that know that they need to go through PA-DSS validation and are looking for real guidance, the other typically involves organizations that are looking for someone to tell them that the standard doesn’t apply to them for some reason.

The questions below are the most common ones that we receive from that second group.  Hopefully, the answers will help those non-POS companies that are wondering whether PA-DSS applies to them.

1.    We are a healthcare (or some other type of) software company, not a POS vendor. We’re not even implemented in a retail setting. PA-DSS doesn’t really apply to us, right?

No, this is not correct. If your situation matches the criteria for the standard (just below), then PA-DSS applies. That doesn’t mean that you have to go through the validation process, it just means that you have to go through the validation process if you want to keep selling your software to companies that accept Visa transactions. Keep reading and I’ll explain.

General Criteria:

  • Is the application being sold, distributed, or licensed to a third party?
  • Does the application store, process, or transmit cardholder data (credit card information)?  Note – ‘process’ doesn’t necessarily mean financial transaction. For example, taking and hashing a card number would be considered ‘processing’ cardholder data.

2.    Our company is really a Service Provider - 80% of our business is hosted, and we only sell our software to a subset of our clients for implementation at their location. We don’t have to bother going through this, do we?

According to the PCI SSC, if your software matches the criteria (see #1), then you need to go through the process. In fact, if you haven’t already, you most likely need to go through the full PCI DSS process as a Service Provider as well.

There are exemptions for one-off, customized solutions, but if you are selling the same base application to two or more clients (and, again, you meet the criteria) you need to address PA-DSS.

3.    Isn’t there some way of doing this more cheaply?

Not really. The process of validating an application under PA-DSS is actually quite involved. It includes documentation review, lab testing, interviewing, process and controls review, documentation, documentation, documentation, and some more documentation.

This is not PABP (if you are familiar with the original Visa software security standard). We have seen significant issues with companies that thought they could treat PA-DSS with the same level of attention and effort as they gave to the older standard.

4.    Are the PCI Council and the card brands trying to put my company out of business?

No - I honestly don’t think so. They are just looking to make sure that applications capable of being implemented in a PCI-compliant manner are what are being sold in the marketplace to handle credit card information and transactions. Their interest is primarily in keeping their card data secure and in making sure that the merchant is choosing applications that will support that goal.

5.    Are they really going to enforce this?

Yes, I think they are. Visa has given every indication that they fully intend to enforce PA-DSS validation and, given their willingness to do so on the broader PCI DSS, I would be willing to bet that they won’t back down.

6.    Do my customers need to have our product validated for them to be compliant with the PCI DSS?

No, your customers are not required by the PCI DSS to utilize PA-DSS validated applications today.

In practice (a point stressed at the recent PCI Community Meeting), Visa will be requiring merchants and service providers to use PA-DSS validated applications (unless the applications are developed internally). That Visa announcement makes PA-DSS a practical requirement (even if not technically a PCI requirement) for companies that want to continue accepting Visa as a form of payment.

7.    How long does the PA-DSS process take?

It actually depends heavily on the software vendor. If they are highly motivated, committed, and well prepared (and timing with the PA-QSA matches up), the process can be fairly quick. This isn’t necessarily typical, however.

At NetSPI we work with our PA-DSS clients in a very interactive manner. We want to identify gaps and allow you to address them prior to testing and review being complete. Closing identified gaps requires the software vendor to take real action; without that action and commitment, the process can really drag. There is little the PA-QSA can do to move the process along without that commitment.

8.    Why are there fewer PA-QSAs vs. PCI-QSAs?

In my opinion, it is due to a few things:

  • Application expertise and app security expertise are NECESSARY for PA-DSS – it’s not quite so easy to throw outside resources at PA-DSS and try to survive on a rigid audit process; you actually have to know what you are talking about.
  • The rigorous QA program that the PCI SSC has implemented on the PCI DSS side was actually ‘turned on’ from day one on the PA-DSS side and required a level of documentation and commitment on the part of the PA-QSA that many in the PCI community simply didn’t want to (or couldn’t) handle.
  • In PA-DSS, the relationship between the firm validating the software and the vendor going through validation is extremely important. This isn’t just about an audit and we’re done. If a PA-QSA firm is doing its job correctly, the QSAs are having discussions with their client about future updates, version control issues, architecture issues, how to operationalize future PA-DSS validation efforts, etc. That’s a consulting/partnership relationship, and many in the PCI community aren’t focused on that type of relationship.

9.    Implementing our solution in our PA-DSS partner’s lab is a real pain, do we have to?

Not necessarily – the council prefers that your application be tested in a PA-QSA’s lab, but it’s not required. If it is impractical for the application to be installed in the testing lab (and your PA-QSA feels comfortable defending that opinion), you can bring the PA-QSA to your location.

10.    We think this whole thing is ridiculous. What if we refuse?

You certainly have the right, but the PCI SSC has been very straightforward: the PCI PA-DSS list is to be the de facto standard on PCI–acceptable applications. If your application is not on the list, you are taking a risk, the potential impact of which would most likely go far beyond the expense of going through the process.

11.    We’ve gone through CCHIT (or some other standard that includes security). Aren’t we covered?

No. PA-DSS is not a suggestion from Visa– it’s a requirement. It is also the only standard that is entirely focused on cardholder data (the data that card brands really care about). If your solution has been successfully audited or validated under another security-focused standard, you may have a head start on getting your solution to a PA-DSS-compliant state. That effort may help prepare you for PA-DSS validation.

Permalink | Email the Author | Subscribe to PCI/PS-DSS Blog

European PCI Community Meeting: Some Impressions

Lee Buttke | Monday, November 2nd, 2009

The trip back to the U.S. from the European PCI Community Meeting in Prague took about 12 hours. For someone who lives and breathes PCI, that equals one hour for each of the 12 requirements of the Data Security Standard (DSS). Here are my impressions of the conference.

First, the PCI Security Standards Council did another great job of bringing the payments community together to discuss current topics and provide feedback regarding the DSS. Second, I met a lot of interesting people and made numerous contacts during the networking sessions.

Third, the meetings were well attended and provided valuable information. I was able to discuss the current state of compliance with European representatives from acquirers, card brands, merchants, service providers, and fellow QSAs. One thing that stands out from these conversations is that the U.S. remains in the forefront of payments security.

Fourth, from a QSA or practitioner point of view, two topics of special concern emerged during the open-microphone sessions: issuers and logging. These two areas were also brought up at the North American Community Meeting in September. So the feedback from the community on both sides of the Atlantic indicates a need for more clarification and guidance on how organizations that are classified as issuers need to comply, and for more guidance on how to review logs.

Fifth, if you ever have an opportunity to visit Prague, make sure to do so. The city is amazing, and the Czech people are very hospitable to visitors. It was a perfect venue for the European PCI Community Meeting.

Permalink | Email the Author | Subscribe to PCI/PS-DSS Blog