PCI DSS – Remaining compliant between assessments

PCI DSS – Remaining compliant between assessments

Senior Consultant, Melanie Taylor

Last week we looked at how to become PCI DSS compliant and you can read our blog on ‘PCI DSS QSAs Demystified’ here

So, you have achieved PCI Compliance! Maybe you completed an SAQ, or maybe you had a full assessment conducted by a QSA. It doesn’t matter, it’s in the bag! Right?

Right! That is, as long as there are no changes that can take you out of compliance.

Small and seemingly innocent changes can have dire consequences for PCI compliance and leave the business at risk of attack.

Examples of changes that may affect compliance:

Ecommerce

Delays in patching

Changes to website code

Network changes

Supplier changes

Logging and monitoring changes

MOTO

Changes in call recording

Changes to the program used to enter card details

Physical security changes

Supplier changes

Logging and monitoring changes

Face to Face

Changes to PED settings

Changes to encryption settings

Network changes

Supplier changes

Its amazing to think that something as small as putting off patching for a week or starting call recording for staff training can have such an impact on PCI DSS compliance, but it does.

Scenario 1:

Imagine a contact centre environment. The role of contact centres is to make customers feel valued and they also want to be careful and diligent when it comes to compliance, so they have implemented processes such as:

  • No phones or smart watches on the contact centre floor
  • No repeating of card details by the agent
  • No writing down of card details

The contact centre would like to improve their customer experience and they decide to record calls to use for analysis and staff training. The contact centre has inadvertently implemented a process that takes them out of compliance regardless of any controls in place. This is because no business is allowed to store Sensitive Authentication Data (SAD), like the CVV (last 3 digits on the back of the card) after authorisation, unless of course you are an issuing bank. This is as black and white as it gets and there cannot be any confusion on the matter, it is simply forbidden.

Solution

If the business wants to record calls, there is nothing wrong with that. However, a process must be put in place which prevents the cardholder details from being captured on the recording. This can be a manual process which allows the call agent to pause the recording when it comes to the time for payment, however, processes must be in place to identify times where card details were inadvertently recorded and delete those calls. Or there are automated solutions, one of which switches the customer to a system which allows them to enter the card details via the telephone keypad and transfers the call back the agent once this is complete. Others include the customer staying on the call with the agent, but the customer enters the card details via the telephone keypad using a technology called Dual Tone multi-frequency signalling (DTMF).

Scenario 2:

A business trading online has discovered that critical security patches have been released and need to be applied.

The release was 3 weeks ago but it’s the busiest period of the year and the website is constantly busy. None of the web developers have time to apply the patches in the test environment because resources are low due to sickness and annual leave. The developers decide to wait for two weeks before starting the process of deploying the patches to give them breathing space and allow them to continue performing their core duties of ensuring that the website is running smoothly and making money.

Requirement 6.2 of the PCI DSS states that you must ‘Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.’

By putting off the deployment the business has ended up being out of compliance and the longer vulnerability remains unpatched, the more likely that it may be exploited.

Solution

Having policies and procedures around patching is a requirement of PCI DSS so making sure that they are followed at all times is a good way to ensure that you remain compliant. Making patching a priority task and following a program to regularly identify and install security patches is an easy way to ensure that they do not get missed or pushed back.

There are other solutions like engaging with a third party or implementing automation software which can also help to ensure that patching is done within the required timeframe.

Change Control

Regardless of the environment or the scope or type of assessment, when you sign the PCI DSS Attestation of Compliance, you are agreeing to maintain PCI DSS Compliance and also if the environment changes, you will reassess it and implement any PCI DSS requirements that now apply due to the change.

If you are not sure whether any proposed changes to the environment will affect your compliance, Bridewell can help you assess the changes. We think of our customers more like partners rather than just a company we assess or implement PCI DSS for and we find that our customers reach out regularly, even just for a sanity check before implementing the changes.

Assessing any changes to ensure that they do not alter the compliance status is a good start to making sure that compliance is maintained. This can easily be built into the change management process.

If you have any questions around PCI DSS or if you would like further information, please just give our team a call on 03303 110 940 or reach out via bc@bridewellconsulting.com

Close Menu