In the realm of PCI, the network of independent agents might not be so independent after all. When one thinks of agents, one thinks of real estate, insurance and travel. They all provide a service, they all take information, and they all accept payments. Some of these are independent agents who own their own agency and are affiliated with a larger organization. The larger organization may or may not also have company-owned branches of its own. At the branches, the agents are generally company employees. At the agencies, they are employees of the agency. Indeed the agency itself is a separate entity from the company. It may be a franchise, or a completely independent business that licenses the company’s name. In addition to Realtors and insurance agents, a number of other companies come to mind - cleaning/maintenance, pest control, and pack-and-ship agents that resell courier services. Indeed it is easy to find many of these agencies in our communities. What are the broader consequences on payment card security, from a corporate, agency and consumer perspective? What would happen if a breach of cardholder data were to occur at one of these agencies? Who would be responsible?
Several architectural models exist for integrating agents into the provider network. An agency may be treated as a virtual branch office, identical to any of the company-owned offices even though the facility, its employees, and its operations are not the company’s own. The company’s IT department might deploy company systems in these agent offices, with full connectivity back to the corporate offices. Each agency employee is treated like a company employee and enjoys similar information access. The independent agency may have operational practices that differ considerably from that of the company’s corporate environment, and these practices may vary greatly from one agency to another.
For example, the company might have adopted a cardholder data retention policy that is strictly enforced in the corporate office, but unheard of at the agency. The corporate office avoids storing hardcopy containing cardholder data while the agency may make their customers fill out paperwork that includes credit card account information. These documents are stored in a file cabinet at the agency. In addition to the agency being unaware of the corporate data retention policy, the same agency is also unaware of a media disposal policy that exists and is practiced at the corporate office - and that calls for shredding of the hardcopy documents when no longer needed. The agency simply throws them in the trash, having never thought about this. Nor should they - they are not the company, they are not in the corporate environment; they are an independent agency, a completely different entity.
Knowing this, part of the contract between the corporation and the agencies might establish specific operational guidelines or might mandate adherence to corporate procedures for all agencies that choose to affiliate with the company. In the face of full corporate responsibility for operations at all of its agencies, this is almost a given for any company with independent contractors, where the lines between home office and agent office blur. When and where a breach occurs might be difficult to sort out, making it difficult to determine where responsibility lies for both parties.
The blurring of operational lines often induces corporations to seek out one of two other models - remote partner model or payment gateway model. In the former, the corporation rolls out its application to the agency using a remote access methodology. This may take the form of a web-based extranet or a client-server model. In the latter, the agency is fully responsible for accepting all payments, but leverages the partner corporation for payment processing.
The advantage of the remote partner model is that the corporation rolls out remote access to its systems to the agents, but retains full control of the operating environment. The line of responsibility between the environments is well defined. For the agency, entering payment information into the “corporate system” frees it from storage, retention, and disposal requirements and obviates the worry for systems operations. For the corporation, there may still be aspects of the agency’s operations that are beyond its control, but its exposure to the risk of data compromise at the agency is limited.
When the corporation-agency relationship uses a payment gateway model for payment acceptance, the agency assumes a greater operational role in the processing of cardholder transactions. The systems are independently owned and operated, as is the agency itself, and payments (of insurance premiums, for example) are made to the agency, not directly to the corporation. In turn, the corporation provides authorization for cardholder transactions to the agency. The transaction belongs to the agency, and it is the agency’s responsibility to secure the cardholder data collected.
Finally, the implication for both parties is this: the corporation (such as the insurance company) may need to be audited as a payment gateway as well as a merchant as part of the PCI process, but the agent environment would be fully out of the corporation’s scope for PCI compliance. The agency as a fully independent organization may need to complete an SAQ or a ROC, depending upon its cardholder transaction volume and its Acquirer. It also means that the agency assumes full responsibility for any breach of cardholder data that occurs at the agency.
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.
As an information security professional, my experience within the payment card security industry has taught me that credit card fraud is not just an information security or information technology issue, but increasingly also a financial one.
In order to process payment cards, organizations must execute agreements with financial institutions (”acquirers”) that legally obligate them to put in place appropriate controls to protect the underlying data. In most organizations, it is the finance and accounting teams that are most familiar with the business processes involved with the acceptance, chargeback and settlement of credit card payment data. Therefore, it is very important that the CFO and finance teams be involved in any effort to construct a sound credit card security program or approach. Such a program should seek to both minimize the risk and the cost of compliance.?The payments community has learned that stolen credit card data is a valuable commodity among criminals; just ask the folks at TJX or Heartland Payment Systems, where breaches resulted in the exposure of credit card data for millions of people.
PCI DSS
The compliance requirements (and the fines for noncompliance) are starting to be pushed down from the credit card companies to financial institutions or acquirers who are, in turn, pushing down to their customers (”merchants” and or “service providers”), contractually requiring organizations to become PCI-compliant. Organizations that have one acceptance channel for credit cards (e.g., a POS or via the web) and use third-party software should self-assess via the Self Assessment Questionnaire (SAQ). Financial professionals should use the published prioritized approach from the PCI Security Standards Council (SSC) to address specific risk areas within their organizations regarding credit card data. Those organizations that have multiple acceptance channels (storefront, Point of Sale and/or via the web) and that store credit card data should involve a Qualified Security Assessor (QSA) if assistance is needed.
Upcoming dates for the standard
There are two important PCI-related dates that are fast approaching, which finance people should be aware of.
July 2010 marks the date after which all merchants must use certified payment applications. A payment application is any application that accepts, transmits or processes credit card data. An example of a payment application is a card swipe machine at a grocery store or a pay at the pump application at a gas station.
September 2010 involves the PCI DSS itself, which will have updates to the standard released that month. These updates will take effect in January 2011.
I am currently on my way back from Las Vegas and the PCI (Payment Card Industry) Assessors Meeting. I guess it is appropriate that the Delta flight that I am on is a cashless flight; you are now able to buy all the $5 Pringles you can eat with a credit card. But I digress; the real update here is regarding the PCI Assessors Meeting that I attended Thursday afternoon. In all there were approximately 30 representatives of QSA (Qualified Security Assessors)/ASV (Approved Scanning Vendors) companies in attendance. The event was not well attended from the perspective of many people that I spoke with, some attributing the lack of attendance on the session not being well publicized.
The meeting provided a summary of the last couple of months within the payment card industry. The monthly newsletter was discussed as well as the relevance of topics covered within the newsletter. Evidence gathering and how evidence is verified provided some information on the top 10 areas for improvement for DSS (Data Security Standard) and PA-DSS (Payment Application - Data Security Standard). Speaking of the PA-DSS, it was reported that there has been a 17% increase in the number of the ROVs (Report on Validation) being submitted. The recently released ASV Program Guide was summarized during the meeting, including the new reporting templates.
The question and answer session lasted longer than the presentation and covered a broad area of topics. There were questions related to assessment methodology and the need to have consistency in approach amongst the QSA firms. The QA Program will be updated in the fall to coincide with the update to the DSS. The updates or potential updates to the standard where not discussed as the card brands and the SSC (Security Standards Council) want to make sure that they adhere to the feedback lifecycle timelines that have been established.
Overall the meeting would have been better received if there was more information provided regarding the proposed updates to the DSS. However, the card brands and the members of the SSC were willing to engage in productive conversation that will benefit the standard in the long term.
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.
Subscribe to PCI Blog
