PCI: Listed vs. Non-Listed P2PE Solutions

credit-cards

With credit card processing, it is important to understand the different parts and pieces that make-up the required security components. The PCI Security Standards Council (PCI-SSC) has released an assessment methodology for merchants using Point-to-Point Encryption (P2PE) solutions. The addition of the Non-Listed Encryption Solution Assessment (NESA) and the accompanying audit process provides merchants an expanded pool of encryption solutions beyond the current list of validated providers, allowing for a wider range of security offerings of the merchant is willing to accept the added liability and cost of a self-certified solution. It is very important to understand the assessment requirements of each before deciding between a listed or a non-listed solution.

The process for becoming a listed solution with the PCI-SSC begins with an audit performed by a third party independent Qualified Security Assessor (QSA) who has been certified specifically for P2PE assessments. During this technical assessment, the P2PE QSA will evaluate the solution against the relevant controls outlined in the following six P2PE Domains from the PCI-SSC:

  • Domain 1: Encryption Device and Application Management
  • Domain 2: Application Security
  • Domain 3: P2PE Solution Management
  • Domain 4: Merchant Managed Solutions (not applicable to 3rd party solution providers)
  • Domain 5: Decryption Environment
  • Domain 6: P2PE Cryptographic Key Operations and Device Management

For each applicable control, the P2PE QSA will collect evidence from the solution and observe all required procedures to ensure compliance with the standard. The results of the assessment are then documented using the P2PE Report on Validation (P-ROV) template which will be submitted by the QSA directly to the PCI-SSC for final review. Once a representative of the PCI-SSC has reviewed, approved, and signed the submitted P-ROV, the solution will receive an official listing on the PCI website.

Transparency_Report

The process of implementing and validating a new or existing solution can be quite lengthy and the NESA process gives solution providers the ability to provide a degree of security assurance to customers, along with scope reduction, while they work towards a validated listing. Much like the process for becoming a listed solution, non-listed solution providers need to engage their own P2PE QSA to perform an assessment of their solution. The requirements for this type of assessment, however, have been relaxed in that a non-listed solution assessment can be completed without meeting the requirements for P2PE Domains 1, 2, or 3, but must meet all applicable requirements of Domains 5 and 6. Though the QSA will still complete a P-ROV for informational purposes, the end result of this assessment will also include a set of documents (referred to as the NESA documentation) which will include:

  • A description of the solution
  • A summary of the application’s full compliance, partial compliance, or non-compliance with Domains 1,2, and 3
  • A statement of compliance confirming the applicable requirements of Domains 5 and 6 are met
  • The assessing P2PE QSA’s recommendation as to how the solution impacts the merchants PCI scope

This set of documents serves the same purpose as a listed solution’s P-ROV or Attestation of Validation (AOV), without being submitted to the PCI Council or the Payment Brands, and will be used by PCI QSA’s when assessing the PCI compliance of a merchant utilizing the non-listed solution. As with standard PCI certification documentation, this NESA documentation should be distributed to clients on an annual basis, and whenever there are significant changes to the system.

At the merchant level, the difference between implementing a listed versus a non-listed solution becomes apparent during the annual PCI-DSS re-certification. A merchant using a listed solution in accordance with the solution providers P2PE Instruction Manual (PIM) and the pre-requisites of the SAQ P2PE automatically qualifies for a drastic reduction in PCI scope when assessing their environment. This is because the security and isolation of credit card data has been verified by a representative of the PCI-SSC. This same level of scope reduction is not guaranteed with a non-listed solution and will really depend on what is permitted by the merchant’s acquirer as well as the payment brands. In some cases, the acquirer or payment brands may require the aid of a PCI QSA to review the solution provider’s NESA documentation and the merchant’s implementation of the solution to determine what PCI-DSS requirements are covered, and to what degree. The results of this secondary solution assessment will determine which areas of the merchant environment are in scope of PCI, but will not qualify the merchant to utilize the SAQ P2PE.

You can get more information from the official PCI Security Standards Council website or your QSA.

Selecting a PCI QSA Vendor

credit-cards

If you are a merchant that accepts credit cards, you are required to comply with the requirements of the Payment Card Industry (PCI) Data Security Standards (DSS), and you must demonstrate that compliance each calendar year to your bank.

You can find more information about what that means to your business here. Once you are ready start your compliance effort, you will need to engage a third-party team to help make sure you are making the correct decisions about demonstrating that compliance, working on changes as they occur to make sure you aren’t making poor security decisions, and they will certify your compliance with a standard format report that lists why they think your environment is secure enough for customer transactions called a Report of Compliance (RoC).

f676e-headache

It can be difficult to find the correct partner that can help guide you through this difficult and expensive process, but a little work in the beginning can save you headaches and expenses later in the process.

The first thing to remember is you need to run your business, and that already means having a secure information technology (IT) environment and worrying about adequate security. Being PCI compliant an having a secure network is not the same thing. The PCI DSS provides you a standard framework that list the minimum requirements for implementing a secure IT environment. You have to know your specific requirements and what makes your environment different than the “standard” IT environment. Your Qualified Security Assessor (QSA) needs to have the skills required to understand technology in general, and your specific environment, before thy can perform their job well.

people-skills

Here are three tips to help you choose the right QSA for your PCI Compliance audit:

  • How experienced is the QSA? You don’t want to pay to train your QSA on how to do perform their job. You want someone who already has a few years of experience.
  • What is the approach to the audit used by the QSA? You have to understand how the QSA will interact with your team and how well their approach will work with your culture and corporate environment. The best-case scenario is they fit seamlessly with your employees and have the professionalism and communication skills to work well with the entire team.
  • Will the QSA stand behind their work? If things go bad and there are questions about your security measures, or even a breach of customer data, you want someone who is confident in their security decisions and will defend your decisions.

Pricing is another area that can be hard to compare from company to company. I looked at 5 different companies and they gave me 5 very different pricing solutions. The cheapest was almost half the cost of the most expensive.  There are several factors that will play into pricing and those factors will vary for each company, but your overall network complexity, number of credit card transactions, and requested services can really drive huge swings in pricing. Don’t be afraid to do some comparison shopping to find a vendor with pricing that meets your budget, but the cheapest vendor doesn’t always mean they are the one you need to select.

It can be preferred to pay slightly more if you are going to get much better service and support.

 

PCI Compliance Requirements – Merchant and Validation Levels

credit-cards - SeniorDBA

If you deal with credit cards, you have to deal with PCI Compliance. What the exact requires are depends on some facts around the types and volume of those transactions.

The first step is to determine your “Merchant Level”, which is based on the type of transactions and the number of those transactions. Using the table below, you should be able to quickly determine if you are Level 1 (the highest level and the most expense to maintain compliance) or if you are Level 2, Level 3, or Level 4. Most small businesses fall into Level 4, but you might have enough volume to move into the other levels. It is your responsibility to verify with your bank as you move into higher levels to maintain your annual compliance.

Different Merchant Levels

Different expectations apply to merchants based on your volume of transactions. Visa ranks merchants according to the following system, applying general PCI Compliance guidelines.

Level Merchant Selection Criteria Validation Requirements
1 Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region
  • Annual Report on Compliance (“ROC”) by Qualified Security Assessor (“QSA”) or Internal Auditor if signed by officer of the company
    • The internal auditor is highly recommended to obtain the PCI SSC Internal Security Assessor (“ISA”) certification
  • Quarterly network scan by Approved Scan Vendor (“ASV”)
  • Attestation of Compliance Form
2 Merchants processing 1 million to 6 million Visa transactions annually (all channels)
  • Annual Self-Assessment Questionnaire (“SAQ”)
  • Quarterly network scan by ASV
  • Attestation of Compliance Form
3 Merchants processing 20,000 to 1 million Visa e-commerce transactions annually
  • Annual SAQ
  • Quarterly network scan by ASV
  • Attestation of Compliance Form
4 Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually
  • Annual SAQ recommended
  • Quarterly network scan by ASV if applicable
  • Compliance validation requirements set by merchant bank

The validation level can help drive the type of compliance requirements based on your merchant level. Work with your bank to verify your validation level.

Validation Levels

A Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Not applicable to face-to-face channels.
A-EP E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e-commerce channels.
B Merchants using only:

  • Imprint machines with no electronic cardholder data storage; and/or
  • Standalone, dial-out terminals with no electronic cardholder data storage.

Not applicable to e-commerce channels.

B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage. Not applicable to e-commerce channels.
C-VT Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels.
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
P2PE-HW Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels.
D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types.
SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete a SAQ.

If you are new to PCI compliance, you can read more here.

Anniversary Of The EMV Deadline

credit cards - @SeniorDBA

Today we celebrate the one-year anniversary of the EMV liability shift on point-of-sale systems imposed by the credit card companies. Credit card companies have declared limited success by showing credit card fraud from Point-Of-Sale (POS) transactions are down from last year, but card-not-present fraud transactions are up from last year.

I have written about how the rollout of new cards to support EMV mandates has been less that effective, and now other people are noting the same issues. This article by Sara Peters talks about the state of the current EMV mandates.

According to a report by The Strawhecker Group (TSG) released last week, only 44% of card-accepting merchants have EMV terminals. What’s worse, only 29% of card-accepting merchants can actually accept EMV chip-based transactions.

“You’re seeing a lot of pieces of paper over the chip readers,” says Jared Drieling, business intelligence manager of TSG. Paper, or maybe tape or stickers, he says.  

EMV Transition in the US is a Disaster

credit-cards

It started about a year ago in the United States. The transition of millions of credit cards from standard swipe cards with a magnetic strip to a more sophisticated card with an embedded chip inside. The new credit cards were supposed to make everyday transactions safer and more secure, but the story that you may hot have heard is it just isn’t working as expected.

Retailers spent a lot of money to meet the mandated transition of the hardware and infrastructure to support the new technology sent out by the major banks, but customers find it confusing, time consuming, and difficult to figure out when and where it will work correctly.

This problem seems to be driven by an inconsistent implementation at the retailers. Some retailers have installed the new software and are unable to support the new technology, resulting in an post-it notes asking you to just swipe your old magnetic strip and most card reading slots being taped over to block the chip readers from even being used.

In this article by Ian Kar, we learn some of the facts about this less than successful rollout:

All of this started when the US decided to move to the chip standard—known in the industry as EMV. The US process was different from those of other countries, where governments instituted a mandate to upgrade everything by a certain date. 

The US implemented something called a “liability shift”—essentially, if retailers didn’t support chip card payments by buying a new, expensive machine, they’d be held accountable for any sort of fraud that occurred in their store. Usually, that’s the bank’s responsibility. So, as long as retailers purchased the new chip-card reading terminals, liability would shift back to the bank. In a July report on the chip card transition in the US, the Aite Group, a financial services research firm, cited a lack of mandate in the US as one reason the chip card transition has been so confusing.

The liability shift date in the US was Oct. 1, 2015. But, when the date rolled around, shoppers were hard pressed to find a chain retailer that actually supported chip cards, let alone a mom-and-pop shop. In a letter from industry trade group Food Marketing Institute asking credit card companies to postpone the liability shift, the group wrote that as of April 2015 retailers were experiencing four-month delays just waiting for their new terminals to arrive.

And just because shops finally got new terminals didn’t mean they’d immediately start accepting chip cards. Their payment processors needed to certify their systems were still compliant and working correctly before the chip readers could be turned on. Even in 2016, they can only do that by physical inspection. That process can drag out for weeks, and some bigger retailers were still verifying their terminals as of early 2016, according to sources that spoke to Quartz.

 

PCI Compliance and DVR Malware

credit-cards

Credit Card compliance is difficult and costly, without faulty vendor software causing additional security issues. Some people have said that faulty firmware found in some security cameras sold by at least 70 vendors may be a contributor to many of the credit card breaches that have recently proved costly to retailers. Rotem Kerner based his research on a paper on the Backoff malware that RSA published back in December 2014. This malware was used to steal payment card details processed by point-of-sale systems at multiple retail locations. The U.S. Secret Service says it impacted over 1,000 U.S. businesses, including Neiman Marcus, Michaels, Target, and UPS Store.

Kerner reviewed the data that RSA collected from computers that were infected with Backoff, and found that many were running small web servers with open ports on 81, 82, and 8000. “Cross Web Server” is running as DVR (digital video recorder) software, which is used by many retailers for video monitoring. But the server software, open to the internet, was left running on the same network as payment card systems. This is an obvious potential security risk that should have been addressed.

The article provides a step-by-step analysis of the code and how to exploit the code to gain access to the target system. He also provides a list of vendor systems impacted by this vulnerability.

In order to exploit it I had to overcome few obstacles I’ve identified –

  1.  Can’t use spaces or newlines + server does not understand URL encoding
  2.  Length in between the slashes is limited.

 I was able to bypass the no-space restrictions with something called ${IFS} . Basically IFS stands for Internal Field Separator, it holds the value which is used by the shell to determine how to do field splitting. By default it holds “\n” which is exactly what I needed.  So this is my new attack vector –

/language/Swedish${IFS}&&echo${IFS}1>test&&tar${IFS}/string.js

And it worked! the file has been written. Lets do another test –

/language/Swedish${IFS}&&echo${IFS}$USER>test&&tar${IFS}/string.js

outputs –

root

 Great success!! As with many embed systems this one is using BusyBox so what i decided to do is invoke netcat in order to get a nice and comfy reverse shell.

Visa Credit Card Development Platform

credit-cards

Most people would have said that this would never happen. Visa is opening up its payment processing system directly to qualified third-party developers. Visa Developer has 150 different APIs to access Visa systems, from simple Visa Checkout and Visa Direct, to more complex solutions things like Visa’s location, foreign exchange, and tokenization services. With services like Apple Pay gaining traction, this is seen as an effort to maintain Visa’s relevance.

The “network effect” is an economics term that basically means a thing becomes more valuable the more people that use it. If Visa can stay on the development radar, it should be able to maintain it’s market dominance. You can read more about the recent announcement here.