Dan Farr
6 min read

Subscribe to our Blog

 

What is the importance of PCI DSS for my merchant?

The migration path to PCI DSS v4.0 can provide a number of significant challenges for larger entities, but in order to understand why you should move to SAQ A v4.0 with the extra control requirements as soon as possible, it may help to first understand the evolution of PCI DSS. Since its inception, the PCI Security Standards Council (SSC) has worked to ensure that the development of the PCI DSS and other PCI security standards balances the need to evolve to face the challenges of a rapidly changing security landscape with the need for constancy. When the PCI DSS standard is updated the goal is to address new or evolving data security threats/vulnerabilities as they emerge.

As a PCI Forensic Investigator (PFI) Company, Foregenix performs hundreds of investigations annually. When we focus on the specific subject of e-commerce site attacks against merchants, a significant percentage of those breaches target the URL redirect process or the iframe implementation which is used to process card transactions. When SAQ A v3.2.1 was released in 2018 the above methods for attacking e-commerce merchants were not actively being implemented; however since its publishing the number of attacks of this nature has grown exponentially.

 

Advanced controls you need to know about PCI DSS SAQ A v4.0

So now we have the background, lets move forwards with the new requirements in PCI DSS SAQ A:

Requirement 6.4.3:

All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: 

  • A method is implemented to confirm that each script is authorised. 
  • A method is implemented to assure the integrity of each script. 
  • An inventory of all scripts is maintained with written justification as to why each is necessary. 

Requirement 11.3.2:

External vulnerability scans are performed as follows: 

  • At least once every three months. 
  • By a PCI SSC Approved Scanning Vendor (ASV). 
  • Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met. 
  • Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.

Requirement 11.3.2.1:

External vulnerability scans are performed after any significant change as follows: 

  • Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved. 
  • Rescans are conducted as needed. 
  • Scans are performed by qualified personnel and organisational independence of the tester exists (not required to be a QSA or ASV).

Requirement 11.6.1:

A change- and tamper-detection mechanism is deployed as follows:

  • To alert personnel to unauthorised modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
  • The mechanism is configured to evaluate the received HTTP header and payment page. 
  • The mechanism functions are performed as follows: 
    • At least once every seven days 

OR 

  • Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

NOTE: These are just the new requirements, requirements which have not significantly changed are not included in the list above. You should check the full SAQ A document for a complete list of requirements.

 

How do PCI DSS v4.0 controls help to mitigate risks?

Now that we have established the requirements, let's look a little deeper into how these controls mitigate the risks associated with compromises of e-commerce sites. 

The first requirement to look at is 11.3.2 (and 11.3.2.1); where SAQ A merchants are introduced to the requirements for external vulnerability scanning using an Approved Scanning Vendor (ASV) provider. External vulnerability scanning is a process where the site is evaluated to identify security weaknesses and issues by an external vendor and a report is provided that details the issues identified and provides some guidance on remediation. 

Next the focus shifts to requirements 6.4.3 and 11.6.1; these controls are defined to specifically mitigate the attack path of changing or tampering with hosted payment pages and iframe implementations. Requirement 6.4.3 provides organisations with a full spectrum control (preventative, detective and corrective) by asking for an inventory of scripts and method to approve new scripts onto the site and monitoring for any changes; timely monitoring against the inventory of scripts is going to be key here to close the window of opportunity during any breach.

Requirement 11.6.1 sounds a lot more technical than it may need to be - the first point to note is that where a forced URL redirect method* is used, this requirement is not applicable.  For implementing requirement 11.6.1 the PCI SSC in the full PCI DSS v4.0 documentation gives the following guidance:

Mechanisms that detect and report on changes to the headers and content of the payment page include but are not limited to:

  • Violations of the Content Security Policy (CSP) can be reported to the entity using the report- to or report-uri CSP directives.
  • Changes to the CSP itself can indicate tampering.
  • External monitoring by systems that request and analyse the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.
  • Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behaviour is detected.
  • Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel.

The above controls will significantly reduce the risk of cardholder data compromise to merchant e-commerce sites; while you can still be PCI DSS compliant without the above controls until the 31st March 2025 (as the new controls only become mandatory after that date), the controls are designed to mitigate risks that are specifically being used to exploit e-commerce systems and applications at the moment.

About Foregenix

We are a world-leading Qualified Security Assessor (QSA), having completed hundreds of PCI DSS Assessments since it's inception.

Foregenix is qualified to deliver against all Assessor programs within all 6 global regions including PCI DSS, PA-DSS/PCI SSF, P2PE, PCI PIN, 3DS and Card Production (CPSA), PCI Forensic Investigation Services (PFI certified). In addition to the PCI standards, Foregenix provides advisory and assessment services for SWIFT Customer Security Program, Security Testing (Internal, External, Web, Mobile and Cloud Application), Information Security Consultancy, Digital Forensics and Incident Response and Risk Management. 

You can also contact us for any specific questions on PCI DSS.

TALK TO AN EXPERT

 

* For details about a URL redirect method please see this documentation from Visa:

https://www.visa.co.uk/dam/VCOM/regional/ve/unitedkingdom/PDF/risk/processing-e-commerce-payments-guide-73-17337.pdf

When Foregenix engages a merchant after a data breach there is often consternation that they have been targeted because they are just a small merchant selling a service, “it is not like we are Amazon/Tesco/Walmart”. The explanation is actually simple - that is why you were targeted.  

E-commerce sites are easy to profile making smaller merchants easy targets, especially those using a certain e-commerce platform. While targeting a large entity or household name could render a single large bounty of cardholder data, the fact is this draws attention from law enforcement, so by rather targeting multiple (hundreds) smaller e-commerce merchants who are all susceptible to the same security vulnerability or attack path, combined with lower security postures, can provide a comparable bounty of data (including cardholder data) without the undesirable attention of law enforcement.

Contact Us

Access cybersecurity advisory services

 

SUBSCRIBE

Subscribe to our blog

Security never stops. Get the most up-to-date information by subscribing to the Foregenix blog.