What are the Key New Requirements with PCI DSS 4.0

What are the new PCI DSS v4.0 requirements around multi-factor authentication (MFA)?

Due to the frequency of password breaches over the previous 3-4 years, MFA has become the default way of preventing these breaches as it offers an extra layer of protection.  When MFA is used, an attacker needs to compromise two systems, instead of one, in order to gain unauthorised access.  In recent years, the focus has therefore shifted from lengthy, complex passwords to MFA, and this is reflected in the changes made to the PCI DSS.

There is significant expansion of where MFA needs to be used in the new version of the Standard.  Previously, MFA was only required to gain remote, admin or privileged level access to the cardholder data environment (CDE).  Version 4, however, requires MFA for any access to CDEs (although point of sale (POS) tills are exempt from this for practicality purposes).

The requirement around remote access with regard to MFA has also been expanded.  Any individual who is able to gain access to the CDE, regardless of whether they actually do so or not, has to use MFA to remotely access your environment.

Can one ‘round’ of MFA be used to gain both remote access and CDE access?

As these are two separate requirements within the Standard, you need to address them separately.  The PCI DSS specifies that you can’t use one requirement to meet another, as the two are there for different reasons. In practice, this means that a remote staff member may need to multi-factor log on twice – once to access your environment, and again to access the CDE.

It is possible that this may incur some pushback from your staff. However, the introduction of MFA makes frequent password changes obsolete, so the unpopular 90-day password lifecycle from version 3 will no longer be necessary.  If your staff are initially reluctant to move to MFA, this could be a useful benefit for ‘selling’ it to them.

Does MFA have to be used going forward with PCI DSS v4.0?  

No, MFA does not need to be used if you don’t have a CDE.  For example, if you have no cardholder data because cardholder functions have been outsourced to third party systems, there are no accounts that would need MFA.  It is still a good idea to have MFA on remote accounts for your own security purposes, but it is not a PCI DSS requirement if you don’t process card data.

What are the new PCI DSS v4.0 requirements
for e-commerce pages?

As the overwhelming majority of fraud is e-commerce fraud, the Payment Card Industry Security Standards Council (PCI SSC) has strengthened the technical systems around e-commerce, focusing on a couple of areas where there have been a number of high-profile breaches.

Unfortunately, these requirements are fairly technical in terms of what they need to do. New requirements have been introduced around scripts, which are programs or sequences of instructions interpreted or carried out by another program rather than by the computer processor.  Scripts are incredibly useful for simplifying web browsing, so are widely used on the Internet.  However, they are not without a downside.  Scripts can be compromised and changed without your computer knowing or your antivirus targeting them.  Scripts are used to manage the content on a web page, as this content often comes from a variety of sources meaning that, if you run an e-commerce site, you may have scripts being inserted by third party providers which you may not be aware of.  This lack of awareness can create a grey area which leaves a page open to attack and exploitation by cyber criminals.

To combat this, PCI DSS v.4 includes new requirements around scripts, with a specific focus on payment pages.  Scripts on payment pages now need to be authorised to run, and integrity checked to ensure they haven’t been edited or changed.  The site operator must also maintain a list of scripts on the site and why they need to be there.  Increased site operator checks and awareness around scripts prevents them from covertly performing unauthorised actions, such as collecting cardholder data.

How can the PCI DSS v4.0 script integrity checking and authorisation requirement be met?

Script integrity checking and script authorisation both use existing technologies but historically have not been treated as standard practice. Some example methods for achieving this that you can suggest to your web-developers include sub-resource integrity (SRI), Content Security Policy (CSP) or proprietary script or tag management systems. Getting web developers and website hosts on board to help you meet this requirement may take some time and effort, as it involves writing new code, deploying new systems or involving developers.

Can the script requirements in PCI DSS v4.0 be avoided?

Not really.  If you have a page that takes payments, this requirement will need to be met. Even if your payment pages are outsourced to a third-party web developer, you will need to ensure they are maintaining the correct checks and documentation around the scripts they use.

Some of our clients have already implemented this new requirement, so it is achievable, even if it does take time and resources to do so.

Are more frequent ASV scans required with PCI DSS v4.0?

Yes.  While ASV scan requirements have not changed in terms of what they are and what you have to do, the definitions of the timeframes in which the scans must be completed have been made much more specific. Previously, scans had to be conducted ‘once per quarter’, effectively giving you a 6-month period to complete two scans.  This timeframe has been made much more specific, and they must now be conducted with ‘no more than 90 days between scans, or on the same date every three months’.  You will need to make sure ASV scanning is being conducted within this timeframe.  Automatic scan scheduling or assigning an individual to regularly check that you aren’t overdue for a scan can both be useful techniques to ensure scan deadlines aren’t missed.

With PCI DSS v4.0, should you stick to the recommended 90-day scan cycle?

We have been recommending that clients conduct monthly scans instead. Usually, this doesn’t entail any further expense as most licences for ASV scanning products include unlimited scans, and they are often automated. If you’re scanning more frequently than is needed, you are guaranteed to meet the new requirement without much increase in oversight.

How will the updated ASV scanning requirement of PCI DSS v4.0 impact self-assessment questionnaires (SAQs)?

The ASV scanning requirement has been added to SAQ A, the smallest and most popular of the SAQs.  The types of merchants which use SAQ A will therefore need to conduct ASV scanning where previously there was no requirement for them to do so.

Do you need a full year’s worth of ASV scans to move from v3.2.1 to PCI DSS v4.0 on SAQ A?

No, you don’t. The PCI has an initial assessment clause, which means that you only need to have enough evidence to prove you’re compliant at the point you’re assessed. This clause can be individually applied to specific requirements that are new to your organisation. If your scope changes and you introduce a new requirement within the year, you don’t need to have a year’s worth of evidence for that requirement. In the case of the ASV scanning requirement, this means you will only need one scan, performed up to 90 days before your assessment date.

Has the scope of PCI DSS changed with v4.0?

Scoping has always been a significant aspect of PCI DSS compliance and, in our experience, it can make or break a PCI DSS assessment.  If your scope is too large, PCI compliance will be impossible, whereas if it’s too small there may be crucial aspects omitted..

In v4.0, the Payment Card Industry Security Standards Council (PCI SSC) hasn’t changed the definition of what is or is not in scope, but it has included extra examples of types of components that could be in scope to cover newer technologies.

However, you are now required to document and confirm your own scope internally at least once a year, as well as documenting when it changes. Previously, when scoping was initially incorrect, the QSA and the entity would work together to correct it prior to assessing the rest of the requirements.  Now, it is the responsibility of the organisation alone to confirm the scope prior to the assessment, without the assistance of the QSA.

To facilitate this, the PCI SSC has included the requirement for organisations to undertake this scoping exercise every 12 months, or every 6 months for service providers.

Do your service providers need to change to PCI DSS v4.0 with you?

The Payment Card Industry Security Standards Council (PCI SSC) has confirmed that it doesn’t matter which version each entity is using.  If the merchant is using v.3 and the service provider is using v.4 (or vice versa), this is not a problem, as long as a valid version was used at the time of assessment.

Can a PCI DSS v4.0 assessment be conducted remotely?

The Payment Card Industry Security Standards Council (PCI SSC) previously assumed that PCI DSS assessments would need to have at least some onsite activity.  However, the move to home working during the pandemic has prompted the Council to shift its attitude towards remote assessment.  While some parts of the assessment have always been conducted remotely for convenience, the PCI SSC has now provided guidance for completing every aspect of the assessment remotely.

You will be able to work with your QSA to determine which aspects of the assessment will be completed remotely, although you will need to justify these decisions.  As long as it makes practical sense to complete an assessment or part of an assessment remotely, and the assessor is able to get the same level of assurance, it is perfectly acceptable to do so.

Does this mean a PCI DSS v4.0 assessment can be conducted entirely remote?

The level of remote assessment will be bespoke to each organisation. Physical security checks will almost always need to be conducted onsite, as there is generally no appropriate substitute for physical attendance. However, everything else is flexible and dependent on the unique setup of each organisation.

What are the changes around evidencing compliance with PCI DSS v4.0?

There have been no changes to the evidence that’s needed to complete a Report on Compliance (RoC) or a SAQ, and you won’t need to provide any more evidence than previous versions, but there have been some changes to how evidence is collected for a RoC.

Previously, QSAs would simply use the evidence table to list which documents were reviewed and which individuals were interviewed.  Now, every evidence piece must be entered into the evidence table.  There are several different evidence tables that document and reference every piece of evidence, whether that be a document, an observed process or system, a sample, etc.  Each piece of evidence is entered as a line item into the relevant table, and referenced against the requirements to prove they have been met.

This change to the way evidence is documented will likely result in your QSA wanting to change to the way the assessment is structured, and you may no longer be able to rely on repeating the plan from previous years’ assessment when transitioning to version 4.

Will this make PCI DSS v4.0 assessments longer?

Initially, yes.  In our experience, the first time you conduct a version 4 assessment, the expanded evidence collection and documentation process, as well as the necessity for extra planning and pre-assessment work, increases the time it takes.  However, once organisations are conducting repeat assessments rather than initial transition, we expect to see a reduction in the time spent on this process.

Why was this evidencing compliance change introduced with PCI DSS v4.0?

The official answer is that the changes will help mature the process and provide flexibility for new technologies and systems that may not have been considered at the time of writing the Standard.  However, there is also an element of refreshing the Report on Compliance (RoC) to prevent stagnation.  While the previous structure of the RoC was easy to produce with little thought, the new structure demands more consideration of, and engagement with, the assessment.

What are v4.0’s customised validations ?

Under previous versions of the Standard, organisations that couldn’t fulfill a requirement for a particular reason had a ‘get out of jail free card’ in the form of compensating controls, which allowed you to compensate for the requirement you were unable to meet.  These could only be used where there was a technological, financial or business constraint that prevented you from meeting the original requirement.

Now, the Payment Card Industry Security Standards Council (PCI SSC) has adapted this to introduce ultimate flexibility for businesses that have found innovative solutions and methods to meet security requirements. Compensating controls are still an option, but you are now given the choice of meeting any requirement the original way, called the standard approach, or innovating your own means of meeting the requirement.

Each requirement has received a statement of intent, which explains what that requirement is trying to achieve.  Your approach must also adhere to the statement of intent, but this is the only limitation.  Requirements can be met however you wish; you can build your own systems or technology, use your own risk management processes, create one customised approach to meet multiple requirements, etc.

With PCI DSS v4.0, can any organisation use customised validations?

In order to use customised validations, your organisation will need to be risk mature.  A robust risk management process is vital to ensure that your approach reduces the risk to the same level as the standard approach.  Customised validations can also only be used as part of a RoC, as they need to be tested by an assessor, so are not available to self-assessing organisations.

On top of this, customised validations are incredibly time and resource intensive.  Preparing for assessment becomes a much lengthier process when customised validations are used, as you are required to produce a formatted matrix that describes your control in detail.  This should include how the control will meet the requirement intent, and the evidence that will prove it does so.  You will need to describe how the control has been tested, how it will be maintained, the risk analysis that shows it reduces risk and how this risk analysis fits within your existing risk management infrastructure.

The assessment process itself is also longer when customised validations have been used. Due to there being no defined way of testing a customised control, it requires much more time and effort from both the organisation and the assessor to work out how they should be assessed.

Ultimately, customised validations are not to be taken lightly.  They should not be treated as a workaround, or as a last-minute fix before PCI DSS assessment if a requirement has been forgotten.  In our experience, it is often more efficient to modify existing systems and processes to meet the standard approach, even when a potential customised approach has been identified.  However, if used appropriately, customised validations can be incredibly beneficial.

Which of the new PCI DSS v4.0 requirements will be the most challenging to meet?

Although the new requirements around e-commerce pages won’t be difficult to implement from a technical perspective, they will likely present a challenge as they will impact every organisation with a payment page, regardless of size.  In order to meet the requirements, you will need knowledgeable individuals to establish how script integrity checking can be implemented, which is going to cost both time and money. Investigating this should therefore be a priority; if you haven’t started thinking about how you will meet the requirements around scripts, now is the time to do so.

Can you still assess against PCI DSS v4.0 if you haven’t met all of the requirements?

Yes, as long as the requirements you haven’t met are the new ones. Requirements that exist in version 3 but have been changed or updated must still be met in a version 4 assessment.

What are the PCI DSS v4.0 changes to SAQ A-EP ?

The new requirements around e-commerce have been added to SAQ A-EP, as it is an e-commerce SAQ.  Organisations conducting SAQ A-EPs outsource their payment processing and, therefore, do not hold any card data, making some of its requirements potentially confusing at first glance as they apply to CDE systems.  However, these requirements are intentionally placed to make your website more secure, so should still be implemented.
‍

How URM can help?

Consultancy

As a PCI QSAC organisation, URM is ideally placed to guide your organisation through its PCI DSS transition journey, or to certifying against the Standard for the first time.  Our team of PCI DSS consultants offer a range of services to help you prepare for assessment, such conducting a gap analysis of your current cardholder processing practices against the requirements of the Standard.  We can also assist with scope reduction, suggesting various segmentation options for you to consider following a thorough review of your data flow and payment channels.  Having conducted a gap analysis and identified the most applicable assessment scope, URM’s PCI DSS consultant can support any implementation and remediation activities necessary for you to achieve compliance.  

Assessment and auditing

Once you are ready for assessment, our PCI qualified security assessors (QSAs) can offer you a range of PCI DSS audit services, including a pre-audit readiness assessment, QSA-led PCI Report on Compliance (RoC), QSA supported SAQs and advising you on SAQs you are completing yourself.  After you are certified, we can conduct regular penetration testing and vulnerability scanning to assess your network infrastructure and applications, as per the requirements of the Standard.