As discussed in a recent newsletter, PCI DSS version 4.0 introduced some stricter controls into the SAQ A to help protect organizations against online payment fraud. With the added requirements for websites utilizing iframes, as well as new external vulnerability scanning requirements for those websites hosting re-direct links to the payment collection pages, it is important for the PCI team to ensure they understand current online payment sites.
Even if your organization is not planning to attest compliance under version 4.0 for some time, we do recommend that you begin gathering an inventory of all e-commerce websites in use by your merchants, reviewing current configurations, and documenting IP addresses and relevant information about any re-direct servers. It will be important to collect:
- Merchant location and MID
- Merchant contact
- Payment process/card flow
- E-commerce URL (where the payment process starts/re-direct link is located – this should be the webserver/website that is one click away from the page where CHD is entered)
- IP address
- Server host (owner/administrator of the server hosting the re-direct link)
- Server contact information (who is responsible for maintaining/updating that server)
- Payment capture website (where the payment card information is actually entered)
- If there is an iframe involved in the process
This may also be a good opportunity to re-engage with many of your merchants and confirm payment processes are documented. If merchants are just utilizing a third-party payment page (i.e. Nelnet CampusCommerce link, Touchnet Marketplace site, Cashnet eMarket storefront, etc.), it can be of value to document how they are sharing that link. Is it posted on an organizational website, or is it just shared via email, paper form, electronic form, via text, on social media, etc.? The PCI team can also verify with the merchants that basic compliance requirements are being met by including questions within a merchant survey or meeting with those responsible for the SAQ A.
- Are credit cards entered on behalf of customers by staff? For example, do customers give you their credit card number over the phone or give you their card in person and then your department processes the payment through the online portal or website?
- (If you get a Yes to this question, then the merchant’s processes will need to be reviewed in more detail to determine if they are following the correct procedures or if the SAQ assignment needs corrected!)
- Identify any third-party service providers (vendors) involved in the online payment process.
- Are you validating the service provider’s PCI DSS compliance status at least annually by obtaining an updated Attestation of Compliance?
If a merchant’s online payment process is entirely outsourced to third-party service providers, the new scanning and monitoring requirements in the SAQ A will fall to the third-party vendor, and the merchant will only be responsible for collecting the annual compliance documentation that confirms that third-party has implemented the necessary controls.
If your organization or department is hosting the re-direct link, that hosting server will need to be added into your quarterly external vulnerability scans. We would recommend setting up a separate quarterly scan from any currently attested CDE scans until your organization is ready to fully move to PCI DSS version 4.0. However, performing these scans now will give your teams ample time to remediate any findings and address any vulnerabilities before the official compliance scans are due to the acquirer.
| SAQ | Description | Penetration Test Requirements | Vulnerability Scanning Requirements |
|---|---|---|---|
|
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 |
None |
ASV external scanning (quarterly) |
|
A-EP |
Merchants accepting only e-commerce transactions that have partially outsourced the e-commerce payment channel to compliant third parties; merchant’s website does not receive account data, but controls how customers, or their account data, are re-directed to the third-party. |
|
ASV external scanning (quarterly) |
|
B |
Merchants using stand-alone, dial-out terminals |
None |
None |
|
B-IP |
Merchants using stand-alone PTS-approved payment terminals with an IP connection to the payment processor |
Segmentation test (annual) |
ASV external scanning (quarterly) |
|
C |
Merchants with payment application systems connected to the Internet, no electronic cardholder data storage |
Segmentation test (annual) |
|
|
C-VT |
Merchants with web-based virtual payment terminals provided and hosted by a PCI DSS compliant third-party service provider |
None |
None |
|
P2PE |
All payment processing is via a validated PCI-listed P2PE solution |
None |
None |
|
D |
Merchants with electronic storage of cardholder data; all merchants not included in the descriptions for above SAQ types |
|
|
|
D-SP |
All service providers defined by a payment brand as SAQ-eligible |
|
|
Your dedicated CampusGuard team can assist and help gather the relevant information from your e-commerce merchants, review merchant SAQ assignments, and configure the required ASV vulnerability scans. Reach out to your team to request our SAQ A inventory template to kick-off this process with your merchants.
Additional technical guidance from the CampusGuard Offensive Security Services and ASV team:
[Strong]:
As you may be preparing for vulnerability scanning with your SAQ A systems, along with ensuring regular patch intervals, it may be a good time to review your site’s security headers for commonly-missed settings, which routinely show up as failures on ASV Scans. The Content-Security-Policy and X-Frame-Options, and X-Content-Type-Options response headers are utilized to tell the receiving browser what they may, or may not, do with the content, and can be effective countermeasures against browser-based attacks.
When a remote web server does not set an X-Frame-Options response header or a Content-Security-Policy ‘frame-ancestors’ response header in all content responses, it could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions. X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is “X-Content-Type-Options: nosniff”.
X-Frame-Options has been proposed by Microsoft as a way to mitigate clickjacking attacks and is currently supported by all major browser vendors.
Content-Security-Policy (CSP) has been proposed by the W3C Web Application Security Working Group, with increasing support among all major browser vendors, as a way to mitigate clickjacking and other attacks. The ‘frame-ancestors’ policy directive restricts which sources can embed the protected resource.
Return the X-Frame-Options or Content-Security-Policy (with the ‘frame-ancestors’ directive) HTTP header with the page’s response.
This prevents the page’s content from being rendered by another site when using the frame or iframe HTML tags. Also, the Server response header will advertise the name and version of software being run on the server, and guidance has been suggesting removing or changing the contents of the header.
Performing vulnerability scans and penetration testing completed is just one piece of the puzzle. Security is an ever-evolving process and company protection efforts should be the same.
