PCI compliance – are you exposed?
The Payment Card Industry Data Security Standard (PCI DSS) requires that merchants accepting credit and debit cards on their websites conform to a set of protocols when processing cardholder data on their website. In certain circumstances, regular vulnerability scans of their environment in order to identify potential security flaws and protect the cardholder data are also needed. However, in most cases, it is simply a case of completing a Self Assessment Questionnaire (SAQ) to establish what process the merchant follows and to ensure they conform to those protocols and protect their cardholder details.
1. Who needs to be PCI compliant?
All merchants that handle credit and debit cardholder data.
2. What’s involved?
Depending on how the merchant processes the card payment on their website will determine what level of SAQ (Self Assessment Questionnaire) they need to complete.
In terms of website and ecommerce environments, there are 3 different levels of compliance depending on how you and your website interacts with the cardholder data. These are referred to as the SAQ level. In each case, your card issuer or acquiring bank will provide you with the required SAQ forms to complete.
3. How do I know which one is correct for my website?
To help you, we’ve put together the following 3 scenarios that cover almost all possible ecommerce situations.
Scenario 1
An ecommerce website that allows users to add items to a cart to purchase, enter their name, contact and address details and then (on clicking to ‘pay’) be passed to the processing gateway page (such as Sagepay, Worldpay or PayPal) to enter the card details – then on successful transaction, the user is then returned to the merchant’s website to confirm the order.
No card details touch the merchant’s website. This is known as SAQ-A and is the most common in the UK. No scan is required but a series of questions need to be answered once a year as part of the SAQ-A level.
Scenario 2
An ecommerce website that allows users to add items to a cart to purchase, enter their name, contact and address details and then (on clicking to ‘pay’) enter the card details directly on the merchant’s website cart page. The details are then stored in the merchant’s website admin system for either customer re-order or refund purposes.
This is known as SAQ-D and requires a quarterly vulnerability scan to be done on both the merchant’s internal network and the web server and you will be required to provide these scan documents to the acquiring bank or processor. Full details of what this means are below – see point A.
Scenario 3
An ecommerce website that allows users to add items to a cart to purchase, enter their name, contact and address details and then (on clicking to ‘pay’) be passed to a page on the merchant’s website where the payment gateway for entering card details are delivered via an iFrame from the card processor or similar and that the merchant website has control over the content of this iFrame. The card details are entered into this iFrame on the merchant’s site (within their domain although the payment processing facility is coming from a payment provider, such as Sagepay, PayPal or Worldpay).
This is known as SAQ-AEP and is less common and unlikely in most ecommerce experiences. However, a full vulnerability scan is required for this process, too.
A. My website works like scenario 2 or 3 – what do I do then?
PCI DSS requires that merchants perform both internal (their office(s) network) and external vulnerability scans on a regular basis to ensure that where you store your cardholder data meets current PCI compliant security standards. The standard requires two different types of vulnerability scan:
External scans should be performed from outside the merchant’s network and include all of the external IP addresses. These scans provide a view of the vulnerabilities that a hacker might use to exploit and get access your network and your stored cardholder data.
Internal scans should take place from a number of different locations within your network to assess the security levels within the network where the cardholder data is stored. This gives an internal view of your security and highlights any possible security vulnerabilities a hacker could us to gain access to your network.
Common and frequently asked questions
1. How often are PCI DSS scans required?
You must perform vulnerability scans at least every quarter and after there have been changes to your network or infrastructure to ensure there are no new security flaws.
These are considered your official PCI DSS document scans. As quoted by Elavon, a major card processor:
“The minimum requirement for a level 4 merchant** is to complete a PCI DSS Self-Assessment Questionnaire (SAQ) on an annual basis and achieve a passing score. If you electronically store cardholder information or if your processing systems have any internet connectivity, a quarterly network vulnerability scan by an approved scanning vendor is also required.”
2. Can we do the scans ourselves?
You can do your own scans to meet the internal scanning requirements, but PCI DSS requires that you use an Approved Scanning Vendor (ASV) for you’re the external scans.
3. What merchants are required to undergo vulnerability scans?
All merchants, regardless of merchant level**, who have external IP addresses must undergo vulnerability scans according to the validation levels outlined above. This is a source of much confusion in the security community and many people believe that level 4 merchants (those who process less than 20,000 e-commerce transactions and less than 1,000,000 total transactions annually) are not required to undergo scans.
This is incorrect, as outlined in Visa’s Cardholder Information Security Program requirements and MasterCard’s Site Data Protection program requirements.
4. What do these PCI DSS vulnerability scans include?
Scans performed by approved scanning vendors (ASV) must meet the following:
i) They must be non-disruptive and should not include denial of service (DoS) or buffer overflow attacks that might disrupt the merchant’s business.
ii) The scan must include a ‘host discovery element’ that searches the network for live systems.
iii) The scan must include a ‘service discovery element’ that includes both TCP and UDP port scans on all live systems.
iv) OS and service fingerprinting must take place to identify the operating characteristics of live systems to the extent practical.
v) Scans must be able to account for load balancers and IDS/IPS systems and provide an accurate view of the customer’s security environment even when these devices are present.
For more information on the specific requirements for ASV scans, see the ASV Program Guide on the PCI Standards Council website.
5. What would an auditor be looking for when auditing a PCI DSS vulnerability scan?
If a merchant is audited, they will perform your PCI DSS assessment and look for the following:
i) Evidence that both internal and external vulnerability scans have taken place for each of the previous four quarters
ii) Evidence that the internal scanning process includes rescans until all “High” vulnerabilities are corrected and the scan provides passing results
iii) Evidence that the external scanning process meets the ASV program requirements for passing, including no vulnerabilities with a CVSS score higher than 4.0
iv) Evidence that the internal scans were performed by an approved scanning vendor or a qualified member of the organisation’s staff who is organisationally independent of the security staff
v) Evidence that the external scans were performed by an approved scanning vendor
vi) Evidence that scans were performed after any significant changes to the cardholder environment
Summary
If you take cardholder data in any format and via any route – you need to look into PCI DSS compliance.
To minimise time and cost, consider using offsite payment pages such as those provided by Sagepay.
PCI compliance isn’t the barrier it once was, especially if you choose the right payment provider.
…………………………..
** Level 4 merchants are required to comply with the PCI DSS but should consult their acquirer to determine if compliance validation is also required. Typically, Level merchants do not process more than 20,000 transactions annually. More information on merchant levels can be read on the Mastercard website here.