In this, the second installment in a series discussing common PCI compliance challenges, I address non-compliant payment applications. Such applications are nearly ubiquitous in the cardholder data environments of smaller merchants (and even some of the larger ones). However, merchants that store cardholder data are rarely able to attain a compliant state when using an application that has not been validated as compliant with PCI standards (either the older Payment Application Best Practices, or PABP, and the newer Payment Application Data Security Standard, or PA-DSS). In particular, compliance with much of PCI DSS Requirement 3, which deals with protection of stored cardholder data, is difficult or even impossible for these businesses, in many cases due to their payment application(s). Typically, such merchants have three options: migrate to a validated solution, work with the vendor of the current application and encourage them to have the application validated, or implement the required controls themselves. Because these applications pose such a high risk to cardholder data, Visa has mandated that all merchants will be required to use validated payment applications, with a deadline established for July 2010 in the U.S. and Canada and July 2012 for other regions. In the meantime, there are several things a merchant can do to meet DSS requirements, the Visa mandate notwithstanding.
In most situations, the best solution is to change the payment application and implement a solution that has already been validated. While this can be a daunting task, especially for larger or distributed environments, it is typically the solution with the most immediate payoff in terms of compliance, especially considering the impending Visa requirement. Chances are good that, if the current application has not been validated, there is a similar application that has been. By migrating to an application that has already been validated, and configuring systems to the standards outlined in the application’s implementation guide, merchants find compliance with DSS requirements much easier.
If moving to a different solution is simply not feasible, though, merchants should pressure payment application vendors to attain PA-DSS compliance by having the application validated by a PA-QSA firm (see https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf). Such a process can take quite a bit of time, which would delay the merchant’s ability to validate PCI DSS compliance. Also, modifying the application can also be expensive for the vendor. However, vendors of these applications should keep in mind that their customer base needs to attain and maintain compliance and it will become increasingly difficult to market and sell non-compliant payment solutions (see http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html).
If a payment application vendor is unable to meet compliance with PA-DSS requirements, merchants may be able to implement a number of controls to meet the PCI DSS requirements. Exactly which controls need to be applied will vary depending on the application, but some key areas can include eliminating storage of sensitive authentication data, obfuscating stored primary account numbers using encryption, hashing, truncation, etc., PCI data discovery on payment systems and servers, increased access controls and logging outside of the application, and implementing key management processes and technologies. Essentially, the payment application would be treated as an internally-developed application, and the merchant would be responsible for ensuring all controls are in place to protect cardholder data. In many cases, the cost of implementing these controls will outweigh the cost of changing payment applications.
When considering these options, merchants should ask an additional question: “Do I actually need to store cardholder data?” In many cases, smaller merchants can be forced to complete the lengthy Self-Assessment Questionnaire D due to the fact that a single application or point-of-sale stores credit card data. These merchants should note that slightly altering their business processes and replacing such a system with one that does not store cardholder data can pay dividends, as compliance requirements would be drastically reduced.
Here we continue our discussion of “what happens when a Merchant outsources their e-commerce environment.” In Part I, we touched on the types of e-commerce operators, including those that are purely e-tailers and those that are mixed brick-and-mortar and online retailers. We began a discussion about scoping the e-commerce environment for PCI, what is clearly in scope and what is clearly out of scope. Now we will examine what is NOT clearly in or out of scope, as well as the implications of different combinations of in-house and hosted environments, and their implications on PCI scope.
But first, let’s review from last time our basic scoping argument for a typically e-commerce environment:
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.”
Let’s take a step back and see what happens on that xyzinc.com website: we start on a “landing” or “splash” page, use certain navigational elements to make our way through the site, and eventually end up with a shopping cart and/or a screen to complete an online purchase. Despite our web-surfing perception that all sites look and act basically the same way, the variability of web site architecture belies what our browser displays to us.
In one scenario, all of the content may be hosted on a single web server (or cluster of web servers with server persistence) environment. Clearly, the server and the applications running on it are within scope for PCI.
In another scenario, the server acting as an agent to complete the online transaction is physically hosted on a different machine, and might even lie in a completely separate network, segmented from the environment that hosts the content web server that brought you here in the first place. Thus the browser experience is seamless – you looked at products and flashy ads on one server, and when you were ready to buy you were handed off to another server that handles the cardholder data and communicates through middleware to a database back end - and the payment processing environment. If the Merchant organization segmenting things adequately, the PCI assessor would rule the first batch of web servers out of PCI scope, and the second batch within scope – as the former does not handle any cardholder data and the latter surely are within the path of cardholder data flow.
OK, now we seem to be getting somewhere. But exactly where? Yes, the question is “where” – where are these machines hosted? Where do they live?
It is entirely possible that the payment processing applications reside in a hosted environment that does not belong to the merchant that owns the website. Thus, the merchant can claim that they e-commerce environment is out off scope. Once again – it depends and it varies. The key to understanding the scope is to understand the flow of cardholder data. What happens to the cardholder data after it is accepted by the e-commerce server?
As a QSA, I have seen cases where the transaction data is sent back to the merchant’s mainframe environment and processed just like any other in-store retail purchase. I have seen others where cardholder data is sent directly from the hosting environment to the payment processor/gateway for authorization. At one retailer, I had witnessed two extreme examples of this – one e-commerce environment that was hosted by a third-party but owned, maintained and developed in-house by the merchant – and a second e-commerce environment that was hosted and managed by yet another third-party provider, as a turn-key solution offered on a “soup to nuts” basis.
Here was a case where both of the retailer’s sites were hosted by a third-party, with one out of scope and one definitely in-scope for their PCI assessment.
Clearly then, hosting of an e-commerce environment by a third-party does not automatically equate to “out of scope” for the retailer. As a matter of fact, the litmus test for scope greatly depends on who operates the website – if it is completely external to the retailer’s environment, if it is developed, maintained and operated by the third-party, and is hosted on equipment that is not owned by the retailer, then the environment is most likely out of scope for the retailer’s PCI assessment. If the site is hosted off-site, but the equipment belongs to the retailer, its web payment applications are developed/maintained by the retailer’s development staff, and the servers it runs on are in fact managed and patched by the retailer’s IT staff, then the site is most likely 100% in scope for PCI.
Some interesting variations: Site is hosted by a third-party, equipment is owned and managed by the same third-party, cardholder data transactions flow directly to the Acquiring Bank’s gateway – and the applications are developed in-house by the retailer (e-commerce environment is largely out of scope, but some elements of this ARE in scope – particularly the e-commerce development processes); Code is maintained by the third-party, a “web hosting” company and the servers are also hosted at the same facility – but the servers are owned by the retailer and the OS is patched and maintained by the retailer remotely (applications most likely out of scope, as is the development environment – but the hardware is in scope for PCI along with the remote access methods and IT administrative procedures. And likely so is the entire e-commerce environment – but not necessarily).
The preceding accounts for some gray shade areas that the QSA must wrestle with when determining the scope for a mixed-responsibility e-commerce environment. As a rule of thumb, the best approach is to consider an e-commerce environment in scope, then determine which pieces of it are outside the scope. As different pieces of the environment are excluded from scope, the blurred boundaries of responsibility begin to sharpen and soon the areas that lie within scope become apparent, as do the areas that can remain excluded from scope. In the end, the scoping section of the Executive Summary of the resulting ROC will read to the effect “In scope: The e-commerce environment, with the exception of the following: <…>” If all areas of the e-commerce environment can be excluded from PCI scope, then a valid argument can be made that the e-commerce environment is out of scope for the assessment. If not, then the exercise results in a narrowing of scope for the e-commerce environment and the fulfillment of our ultimate goal.
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.
In late March Thales released an interesting report on the state of PCI – “PCI DSS Trends 2010: QSA Insights Report.” The report was written by the Ponemon Institute and it highlights the difficulty of taking into account risk, security and subjectivity within the PCI DSS compliance standard. If you haven’t read it, here’s a link: http://iss.thalesgroup.com/l/program/pcitrendsreport.aspx.
First, the insight that only 2% of organizations fail their PCI audits should raise some eyebrows. Taking it at face value (and there’s certainly room for discussion about that) it indicates that, in general, retailers and payment processing related organizations are taking PCI compliance seriously. However, when combined with another observation in the report, that about 40% of organizations are relying on compensating controls, it illustrates the subjectivity of the standard and of the “auditing” process. There are a number of other conclusions that can be drawn from this high pass rate, and hopefully, the Council will look into them.
Second, the report says that over 50% of the QSAs surveyed observe that information security is still not being taken seriously by the organizations they are auditing. Even though almost all of the organizations covered in the review are addressing PCI, most are not truly addressing security and, by extension, risk – which is a level of maturity that usually requires enlightened management or a breach. This finding further highlights how important it is for audits to be done by competent and honest auditors. Like the point above, this gets at the core of PCI - the standard and the associated subjectivity should evolve to ensure that security and risk be addressed, not just compliance.
Finally, the report states that QSAs feel that firewalls and encryption are the most effective technologies used to protect cardholder data. The number of organizations that think they are doing one thing (with technology) and are actually doing another is amazing. ASV scanning is a very important component of verifying technical compliance, but with self-attestation for many internal components it doesn’t cover nearly enough. With this in mind, the PCI Council should implement further verification to ensure that technology and controls are implemented properly. This would continue to drive the convergence of compliance and security. More reviews - especially third-party - would also help organizations better understand risk and develop mechanisms to mitigate it programmatically.
Overall, the report says as much about the state of the PCI standard as it does about the organizations it covers. Some of the more interesting insights are the implications surrounding PCI’s subjectivity and maturity. The positive take away from the report is that it appears organizations affected by the initial PCI focus (retailers and payment processing-related firms) are taking PCI compliance seriously. To achieve the common goal of reducing IT risk related to PCI data, hopefully the Council will be able use this report (and other similar reports) to enhance the standard to cover more security and risk.
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.
Subscribe