NO TIME TO READ NOW?
Download your free eBook now so you can read later when you have more time!
Mastercard has set a deadline for acquiring organisations to manage risk in their Level 4 Merchant portfolio. Mastercard’s updated Site Data Protection (SDP) Program rules expect PCI DSS compliance validation from your high-risk merchants.
Mastercard requires all acquirers to have a Level 4 risk management programme in place to meet the updated SDP requirements.
The key question in developing that programme and setting a compliance deadline for your high-risk Level 4 Merchants is:
‘What is it that makes a Level 4 Merchant high-risk?’
There are a number of factors, indicators and business characteristics that can help to identify higher risk merchants in your portfolio. These include:
Merchant business type (MCC code)
The MCC code may help to identify merchant types that may be operating business practices that
put card data at risk, for example:
• Hotels where the booking process often involves storing electronic card data in property management systems, often well in advance of the guest’s stay and maybe long after they have checked out.
• Travel agents who may store electronic card data in travel booking systems, to simplify the process of taking final balance payments.
• Ocean and river cruise companies whose guest boarding process requires registration of a payment card for on-board spending. They may be batch processing pre-authorisation or retaining the electronic card data in a database for the duration of the cruise.
• Regulated industries such as finance, investment or insurance companies who are obliged to record their customer calls and may also be capturing (and storing) PAN and SAD in those call recordings.
• Services industries that operate appointment systems and charge in the event the customer doesn’t cancel in time, such as physiotherapists, cosmetic surgery and private practice, beauty treatment/spas etc.
• Merchants that operate venues and function rooms – they may process an initial deposit but retain the card data post-authorisation to take the final balance payment.
Higher risk payment channels include:
• Merchants operating an online e-commerce payment channel – a payment channel exposed to the Internet, therefore at greater risk of cyber-attack, and which may be directly handling payment card data (for example, if using the direct integration e-commerce method).
• Merchants accepting card not present telephone payments – calls capturing PAN and SAD may be recorded and stored insecurely, agents may not be adhering to good practices (not writing down card data, not repeating card details out loud).
Payment method (card data handling)
For each payment channel there are payment methods that are riskier than others, for example:
A merchant website set-up for full URL redirect to a hosted payment page provided by a PCI DSS compliant service provider will be less risky than one whose website is set-up with the direct integration method, as the latter merchant is capturing card data on their own payment page and sending via API to the payment processor.
There is a greater risk of compromise of card data if a merchant handles the card data on their own website rather than relying on a PCI DSS compliant third party to capture and process the card data.
• Mail Order
Merchants processing card not present mail order payments will be less risky if they only receive payment card data in hard copy, i.e. mail order forms, fax (but not eFax), and do not accept the payment card data via electronic, Internet-based methods such as email, efax (fax to email) or other end user messaging methods (chat, instant messaging etc.).
• Telephone Order
Card data may be more at risk where merchants submit payment card data for authorisation via an integrated payment page built into their order processing system. These merchants may also be retaining the card data within those systems (which may be poorly secured) when they have no business need to.
Merchants whose order processing systems link to a third party payment page hosted by a PCI DSS compliant service provider are minimising risk, as the card data is entered directly into the third party payment page.
Merchant accounts, transaction volumes and self-assessment questionnaire (SAQ)
More complex and higher risk merchants may be identified through an aggregated review of merchant accounts, transaction volumes and Self-Assessment Questionnaires (SAQ).
• A merchant with a large number of merchant accounts, processing a high volume of card present only transactions, profiled as SAQ B for all merchant accounts, will be lower risk than;
• Another merchant with an equivalent number of merchant accounts, processing a lower volume of both card present and card not present (e-commerce and non-ecommerce) transactions, and profiled as multiple SAQs or SAQ D to cover all merchant accounts, is operating a more complex card processing set-up, has many more in-scope processes and systems and hence is higher risk.
Asking merchants about the hardware terminals that they use could reveal higher risk merchants,
• Merchants in the U.S. that have not yet transitioned to EMV-enabled terminals. With EMV transactions even if the transaction data is obtained by hackers, it cannot be used to successfully process future transactions; unlike magnetic stripe data, the target of POS malware, which can. EMV reduces the risk of face to face counterfeit card fraud.
• Merchants using payment hardware that is not PCI PTS approved. They may be using devices that have never been PTS approved or devices where the deadline for removing them from use has passed (e.g. PCI PTS v1.x devices).
Devices that are not PCI PTS approved have not been independently proven to be tamper proof and capable of protecting both the PIN and other payment card data captured by the devices.
• Merchants may be using hardware devices such as simple plug-in magnetic stripe readers or a keyboard with a built-in magnetic stripe reader to speed up the process of keying card data into virtual terminals or payment applications. Use of these devices could mean unencrypted, plain text card data is at risk of exposure on the merchant’s systems.
PA-DSS applications and use of QIR
Gathering information from your merchants about their payment applications and the vendors or resellers that implemented them can identify risky merchants:
• If merchants use a third-party payment application to facilitate their payment authorisation that is not PA-DSS validated, the application may not be securing the card data it processes, transmits, and that it may also be storing, in line with PCI DSS requirements (e.g. in its use of a secure communication protocols such as TLS 1.2, in enforcing role-based access controls to allow restriction of user access based on need to know/job role, generating audits logs of application and user activities, or in strongly encrypting stored electronic card data).
• Even when merchants select approved PA-DSS payment applications, they may be inadvertently increasing the risk to card data. Their POS vendor may not make them aware of or know to implement the requirements in the application’s PA-DSS Implementation Guide.
Merchants that have implemented and integrated third party payment application systems in their environment but without engaging a Qualified Integrator and Reseller (QIR) may be putting their systems and card data at risk, due to insecure implementation and configuration of the application (such as leaving default passwords in place) and enabling/using insecure remote access methods for support, etc.
Third-party service providers
An understanding of the service providers a merchant relies upon, the services they provide and whether those third parties are validated PCI DSS compliant service providers can identify card data risk.
Finding that the third-party provider is listed on the Mastercard or Visa Global register of service providers can provide additional security assurance, as all providers on those lists must be a Level 1 Service Provider (externally assessed by a QSA).
Identifying that a merchant’s service provider is listed with Visa Europe as a merchant agent (both Level 1 and Level 2 Service Providers) can also provide assurance as it indicates that the third party has an awareness of PCI DSS, their obligations and has agreed to report suspected or actual card data breaches and participate in any investigations.
Merchants often think they have ‘outsourced’ the need for PCI DSS compliance by engaging third party service providers to store, process, or transmit cardholder data on their behalf, to manage system components or to provide fully outsourced services. They often don’t realise that as the merchant of record with you, their acquirer, they retain the responsibility for the protection of cardholder data and fulfillment of applicable PCI DSS requirements by their service providers.
For example, a merchant may believe that they have fully outsourced the development, hosting and management of their e-commerce website to the digital agency they engaged to build their website; therefore, the digital agency is fulfilling all of the PCI DSS requirements.
This is often not the case, many times when e-commerce breaches occur it is due to ‘grey areas’ of responsibility; the merchant thinks the digital agency was patching the website, although it was in fact the hosting provider’s responsibility. The hosting provider did patch the operating system but wasn’t responsible for patching the web content management system (see Figure 1).
Figure 1 : The e-commerce website is at risk of compromise if responsibility for applicable PCI DSS requirements isn’t understood and assigned.
The same problems can occur even when the merchant is diligent enough to check their service provider’s PCI DSS compliance status.
The merchant may think that they have confirmed that their hosting provider is PCI DSS compliant (e.g. by obtaining a certificate of PCI DSS compliance) but forget to ask what that compliance covers or confirm whether that compliance certificate is relevant to the services delivered to the merchant.
For example, a managed network provider may offer services that are covered by their PCI DSS assessment scope, but in fact that scope does not include the provider’s managed firewalls/routers deployed to each merchant retail store; or the hosting provider that has been assessed only for Requirement 9 (physical security) and Requirement 12 (information security policy), the merchant cannot rely on that service provider’s compliance for the secure configuration, management and operation of the hosted servers or of the firewall that protects them even though they are in the provider’s hosting facility.
Use of a QSA or ISA to complete the compliance assessment (SAQ)
Some merchants, particularly the larger Level 4 Merchants (e.g. those that are high value low volume merchants or high volume card present merchants) may have the resources to engage a Qualified Security Assessor or send an internal resource on Internal Security Assessor (ISA) training.
Identifying those merchants that have done so can be a factor that may help to discount these entities as high-risk merchants to be targeted for compliance validation. Just because these merchants haven’t validated their compliance with you yet doesn’t mean that they aren’t committed to taking the necessary steps to achieve compliance.
Storage of Primary Account Number and Sensitive Authentication Data
Gathering information on payment processing methods, card data handling and retention of card data (in hard copy and electronically) will help identify higher risk merchants such as those that:
• Retain card data electronically in CRM or ERP systems, property management systems, booking and payment systems etc.
• Are under the misconception that they need to retain card data in order to support a subsequent purpose, e.g. for processing recurring payments or refunds, to take final balance payments.
• Record their telephone payment calls but have no method in place to ensure card data is not captured in the recordings.
• Not only offer email, SMS and other end user messaging technologies to communicate with customers but are willing to accept or proactively support acceptance of card data over these channels.
• Collect and store card data rather than authorising the payment in real-time at the time of purchase, often because they don’t want to charge the card until dispatch (as goods may not be in stock or the final shipping cost is not known) often because they don’t want to charge the card until dispatch (as goods may not be in stock or final transaction cost is not known).
Merchants that are not adhering to good security practices
Merchants that are not protecting their systems and their business by following good security practices are at increased risk of cyber attack, data breach and card data compromise:
• They allow the use of default, generic or shared accounts and therefore also use of shared passwords;
• They allow the use of weak passwords that can be easily guessed or brute forced and do not set password policies, such that accounts never lockout after multiple failed log-on attempts;
• They use insecure methods of remote access that do not rely on multi-factor authentication for remote users and grant ‘always-on’ access to third party support and service providers;
• They use out of date systems and software. Systems are not maintained leaving them vulnerable to malicious software or attack because security patches for known vulnerabilities have not been applied.
In some cases, the software is no longer supported by the vendor; security updates to address these vulnerabilities are not available.
• Protection measures against viruses and malware are insufficient.
The risk may range from merchants that do not have any anti-virus software, those that use free anti-virus software that has limited capability, to those that do not protect their servers and protect only some end-user device types (e.g. only Windows workstations).
• They rely on default out of the box settings for their wireless access points and firewalls/routers.
Many merchants do not set-up firewall rules to permit only what is needed for business activities which could leave their networks open to compromise, including the leakage of sensitive data out of their network.
Sysnet’s proposed solution
Sysnet’s compliance management solution can help you combine existing knowledge of risk factors (such as MCC code, transaction volumes, etc.) with information obtained directly from the merchant to help you identify and target high-risk merchants; this may be all high-risk merchants in your portfolio or specific categories of merchant fulfilling specific key risk indicators.
Armed with detailed information on risk within your merchant portfolio, you can take steps to address that risk and fulfil Mastercard’s requirements:
• Communicate and engage with merchants to reduce their risk. For example, based on your merchant categorisation you may wish to: educate merchants on risky behaviours or activities; raise awareness of good security practices; offer security tools and services that will improve the business security posture and protect from malware and cyberattacks; inform them of payment solutions, products and
processes that will reduce risk while fulfilling business operational needs (such as PCI PTS approved hardware, P2PE Solutions, hosted ecommerce or tokenisation).
• Set compliance validation deadlines to encourage engagement with the PCI DSS compliance process and action to reduce risk, achieve and maintain PCI DSS compliance.
If you are a merchant that requires technical or PCI DSS help, please click here