How to reduce your PCI DSS scope and CDE
The PCI DSS (Payment Card Industry Data Security Standard) – now at v4.0.1 – can appear intimidating, at 360 pages, listing 277 prescriptive sub-requirements.
But this robust standard, administered by the PCI SSC (Payment Card Industry Security Standards Council), recognises that not every organisation accepting card payments needs to meet all 277 requirements.
If you can reduce the risk of data breaches and card fraud by reducing your scope, you can reduce your compliance burden to as little as 21 sub-requirements (SAQ P2PE).
Let’s look at eight ways you can reduce your CDE (cardholder data environment) to reduce your PCI scope.
In this blog
- Don’t store unnecessary data
- Network segmentation
- Restrict access
- Tokenisation
- SPoC solution
- DTMF masking
- P2PE encryption
- Web page redirects
1. Don’t store unnecessary data
When it comes to the security of account data (cardholder data and SAD – sensitive authentication data), you should never store data you don’t need.
The same applies to personal information and the GDPR (General Data Protection Regulation): the data minimisation principle says to not store or process more personal data than you need.
In fact, you should follow that principle no matter the data type.
This reduces the potential impact of any breach, whether deliberate or accidental. If you don’t have the data, it can’t be stolen or misused. It also saves you money on storage costs.
Plus, if you electronically store any account data on your own systems or premises, you need to complete SAQ D (or meet its equivalent requirements in an audit) – the most arduous SAQ.
Avoid storing PANs
A particularly common – and mistaken – belief is that you need to store all account data you collect for accounting purposes.
In fact, if you’re a merchant, you probably don’t need to store PANs (primary account numbers). Though the PCI DSS does permit this, doing so significantly increases the number of requirements you must meet – and, by extension, the number of controls to put in place.
If you need access to the PANs to, for example, process recurring transactions, you can still avoid storing them by using a tokenisation solution.
2. Network segmentation
Effective network segmentation separates the CDE from other business areas.
This means you can cost-effectively apply your security measures, implementing them just for the CDE, and not for other network areas (unless they require the same high level of security).
In addition, if an attacker gets into your systems, the segmentation will make it harder for them to move through your networks. This buys you time to detect the attacker and stop them from elevating their privileges, limiting the impact of the incident.
To deem a system component out of scope, it must be completely – and correctly – isolated from the CDE. In other words, if compromised, the out-of-scope component must be unable to affect the CDE’s security.
You can check how effective your segmentation controls are with penetration testing.
3. Restrict access
Another simple but effective measure – to simplify PCI compliance and generally improve security – is to restrict access.
Access control best practice says that staff should only get access to the CDE (or any other sensitive data) if they require it for their job.
The same goes for other resources requesting access – only grant it if necessary. So, for PCI DSS purposes, you should try to remove all wireless access to the CDE to reduce the scope.
(If you can’t for business purposes, put an extra firewall around the wireless network and restrict access to the bare minimum.)
You should also check your network diagrams for other unnecessary inbound traffic into the CDE (and other sensitive environments).
4. Tokenisation
Tokenisation solutions generate a unique ‘token’ (typically a string of random characters generated by an algorithm) to replace the PAN.
The merchant stores the tokens, while a TPSP (third-party service provider) stores the encrypted PANs. That way, if you (the merchant) suffer a breach, only the tokens can be stolen. These are of little use to an attacker.
(Should you need access to the PANs to process a recurring transaction, you can provide the token to the TPSP, which then looks up the associated data and completes the transaction.)
But, as with any outsourcing, the responsibility of compliance remains with the merchant. That means you must check that you’ve correctly and securely implemented the tokenisation – that PANs can’t be retrieved from any out-of-scope system components, for example.
We also recommend using a data discovery tool to find all PAN caches and replacing them with a token, or otherwise confirm you’re no longer storing any PANs.
Finding this blog useful? Subscribe to our free
weekly newsletter – the Security Spotlight – to
get future posts direct to your inbox.
5. SPoC solution
Merchants that only take face-to-face payments via fully attended channels can implement a SPoC (software-based PIN entry on COTS) solution to potentially qualify for SAQ SPoC.
You must also only take card payments via SCRPs (secure card readers for PIN) to qualify. Plus, the SPoC solution must be PCI SSC-validated.
SPoC solutions – mostly provided by a third party – comprise:
- An SCRP;
- A PIN CVM (cardholder verification method) application; and
- A back-end system – a remote service provided by the SPoC solution provider – that monitors the entire SPoC solution for any potentially malicious activity.
You also need your own COTS (commercial off-the-shelf) device, such as a smartphone or tablet.
The idea of a SPoC solution is that when customers enter their PIN, that data is isolated from other SAD, making it harder for an attacker to breach all data at once.
6. DTMF masking
Merchants that both record calls and take card payments by phone often either:
- Pause or stop recording when the cardholder provides their card details; or
- Revisit those recordings later to mute or mask the card data (after manually tagging those calls).
Both approaches have significant drawbacks, including administrative burden and risk of human error. It also disqualifies you from one of the simplest SAQs: SAQ A.
If you instead implemented a PCI DSS-compliant DTMF (dual-tone multi-frequency) masking solution, you could qualify for SAQ A.
This solution lets cardholders use their phone keypad to enter their card details. The DTMF masking then overlays the keypad sounds (with some type of white noise) so no one can work out the card details auditorily.
The DTMF solution also sends the card data straight to your payment processor, so it doesn’t enter your environment at all. (Assuming you’ve correctly implemented the solution.)
7. P2PE encryption
MOTO (mail order/telephone order) and face-to-face merchants could implement a P2PE (point-to-point encryption) solution to potentially qualify for SAQ P2PE.
P2PE solutions, provided by a third party, comprise:
- Secure devices, applications and processes…
- That encrypt account data…
- From the point of accepting payment…
- Until the data reaches the P2PE provider’s secure decryption environment.
If you correctly implement a PCI SSC-validated P2PE solution, account data will be less valuable to anyone intercepting it in transit, reducing the impact (and therefore overall risk) of a breach.
8. Web page redirects
E-commerce/online merchants can implement a web page redirect to qualify for SAQ A.
Redirects send customers, when checking out, to a new window or an iframe – a secure page, hosted by a PCI DSS-compliant TPSP. This third party will verify the validity of the payment card and perform authorisation.
Upon payment completion, the customer gets redirected back to your (the merchant’s) website, so you don’t handle or store any account data.
The redirect solution is within scope for PCI DSS compliance, because an attacker could hijack the redirect. You also remain responsible for security and compliance, and may face challenges because of that.
That said, you have far fewer requirements to meet than without the redirect, and are exempt from more arduous requirements like penetration testing.
You can further reduce your requirements by fully outsourcing your website. But if you do, make sure you still conduct your due diligence (which QSA – Qualified Security Assessor – Stephen Hancock explains here).
Need tailored PCI DSS advice?
Get a detailed review of your cardholder data flows with our PCI DSS Scope Assessment and Reduction service.
A QSA consultant will help:
- Draft data flow diagrams;
- Evaluate segmentation; and
- Define the scope for PCI DSS compliance.
The QSA will also advise on how to reduce your scope, simplifying your compliance and saving you money.
Need other PCI DSS support? Speak to an expert.
We first published a version of this blog in November 2012.
The post 8 Ways to Reduce Your PCI DSS Compliance Burden appeared first on IT Governance UK Blog.
