The word “scope” gets used a lot when you’re talking about PCI DSS. But it is also often misunderstood. This article provides some basic information about scope and how to start understanding what is in-scope for PCI DSS.
Who is Responsible for Scoping?
Both you and your QSA need to be able to understand the scope of your environment.
As a merchant or service provider, you are responsible for:
Defining your scope
Documenting your scope
Reviewing your scope for accuracy
Your QSA is responsible for validating the scope that you have defined.
That makes it even more important to make sure that when we talk about scope, everyone has the same understanding.
In-Scope or Out-of-Scope?
One of the biggest mistakes the people make is considering that only those systems that store, process, or transmit cardholder data are the only things that is in-scope for PCI DSS. Collectively, this set of systems is referred to as the Cardholder Data Environment, or CDE. But there will always be other systems that come into scope for PCI DSS. We recommend reading the PCI SSC’s Guidance for Scoping and Segmentation, but we will summarise some of the key points here.
In-Scope
For a system to be in-scope for PCI DSS, it only needs to meet any one of the criteria in the bullet points below.
The CDE consists of any systems that:
Store cardholder data
Process cardholder data
Transmit cardholder dat
Is in the same VLAN as a system that stores, processes, or transmits cardholder data.
Other systems that are in-scope for PCI include:
Systems that are directly connected to the CDE
Systems that are indirectly connected to the CDE
Systems that impact the configuration of systems in the CDE
Systems that perform security services
Systems that support PCI DSS requirements
Systems that provide segmentation.
Out-of-Scope
For a system to be out of scope, it needs to meet all of the criteria from the bullet points below.
Not part of the CDE
Not in the same network segment as the CDE
Cannot connect directly to the CDE
Cannot connect indirectly to the CDE
Does not meet any of the CDE or in-scope criteria
Overall, for a system to be out of scope for PCI, it should not be able to connect in any way to the systems that are. It is possible to have shared security services. But you need to make sure that it does not grant any unintended indirect access to the CDE.
How Do You Scope?
We recommend that you start by asking yourself some key questions about your systems and data flows. To start, make sure you have all your key documents and people in a room. This means things like your network diagrams, cardholder data flow diagrams, and people who understand the networks, systems, and applications.
Then you can start asking questions to understand more of your scope, such as:
Are all the payment channels included in the cardholder data flow diagrams? Do we have any other channels where we get cardholder data or export it?
Where is credit card data stored, processed, or transmitted? If you don’t store, process, or directly transmit cardholder data, how do your customers transact and how do you protect the transaction process?
Have you identified each system that performs a function as part of a PCI requirement?
Are all of the systems you’ve identified so far on the network diagrams?
Have you looked at the firewalls to identify any connections to the CDE?
Have you looked at your system inventory to identify what else sits in your CDE?
Once you start answering these basic questions you get a better idea of what might be in-scope for PCI DSS and how you can remove things from scope. While this level of detail may seem like a lot of work, it will help you develop a clear picture of what your environment looks like and help ensure that you are applying the relevant PCI controls to avoid scope creep and surprises during your assessment.
Need Help?
If you need help with scoping, Confide can assist with scope reviews regardless of your size or transaction processes. Contact us to find out how we can help define, document, and in some cases reduce your scope.
Currently, there is no requirement to use a PCI compliant service provider (although the card brands and banks may require you to do so). If you are outsourcing some of your compliance responsibilities to a third-party, you need to understand what this means for your own PCI DSS compliance.
If you use a service provider for something that is in-scope for your compliance, they need to be able to demonstrate that they are providing that service in a compliant manner. This can be done either by:
Having the service provider provide their current Attestation of Compliance (AoC) (and Responsibility Matrix if they have one) which covers the service they are providing OR
Including them within the scope of your assessment either at your cost or an agreed shared cost.
If your Service Provider can provide you with an AoC, you need to make sure that you keep a copy of that for your records and for your QSA to review. And make sure that if you’re expecting them to be responsible for a requirement that it is covered within the scope of their AoC. Finally, make sure the Service Provider provides you with an updated AoC annually.
But since our focus is on Service Providers who cannot provide an AoC, let’s look at how that will affect the scope of your assessment.
What Does it Mean to Include Someone in the Scope of Our Assessment?
Put simply, this means that your QSA would expect to be able to review the way that the third-party provides the services to you to ensure that they are meeting your compliance requirements.
This means that your QSA will need to conduct interviews with them, review their system configurations, review their processes, and review their documentation depending on what services they are providing.
What itdoes not mean is that everything done by the service provider comes into scope. Only the processes and services they provide to you as well as some potential supporting services will be in-scope.
One common example of a service provider without an AoC that we see is data centres and physical hosting. While more data centres are doing PCI compliance (we do strongly recommend checking this as part of your due diligence when signing a contract with them) it provides an easy example of how including someone in your own compliance review works.
If a data centre is included in your assessment and they do not have an AoC, your QSA would visit the data centre, observe visitor logs and CCTV footage, look at access logs (for your racks), physically check to make sure the racks are locked, observe visitor processes, and interview staff about these processes and supporting processes.
While this is just one example, the high-level processes are the same. Your QSA needs to verify that the service is being provided in a way to ensure you can become (or remain) PCI DSS compliant.
Other Considerations
One of the most important things to consider is making sure that your Service Provider is aware of the need for them to provide a compliant service. Review the services you are using and make sure that each Service Provider:
Is aware of their PCI requirements AND
Has acknowledged their PCI requirements
Where possible there may be a contractual obligation for the Service Provider to be PCI DSS compliant. Most importantly, doubly ensure that you have a right to audit built in to your contracts so that you’re not leaving things to chance if they aren’t PCI compliant or they fall out of compliance.
Now What?
With a basic understanding of your Service Providers, the next step is to build a responsibility matrix so that you understand which Service Providers are responsible for which PCI DSS requirements. You can find more information on the PCI SSC Third-Party Security Assurance and Shared Responsibilities document on page 43, or Confide can assist you in understanding your service providers and how they affect your PCI compliance.
Need More Help?
If you need more help to understand how your Service Providers could affect your PCI compliance, contact us to find out how Confide can help.
The Payment Card Industry Data Security Standard (PCI DSS) requires several types of scanning to be completed. This article provides an overview of the types of scanning, frequency for scans, and what it typically applies to in the environment. The table below provides a summary of this.
Scan Type
PCI Requirement
Required Frequency
Recommended Frequency
Cardholder Data Scanning
Validation of Scope – Card scanning is one option
Not required
Quarterly to validate scope
Web Application Scanning
Req. 6.6
After any change
Daily
Rogue Wireless Scanning
Req. 11.1
Quarterly
Quarterly
Internal Vulnerability Scanning
Req. 11.2.1
Quarterly
Monthly
External Vulnerability Scanning
Req. 11.2.2
Quarterly
Monthly
Validate Scope with Cardholder Data Scanning
PCI DSS does not require you to specifically complete scanning for cardholder data unless you are completing an S-RoC (Supplemental Report on Compliance) / DESV (Designated Entities Supplemental Validation). However, customers often use cardholder data scanning to validate the scope of their assessment or to validate that they can use a particular self-assessment questionnaire (SAQ) which requires you to attest that you are not storing any cardholder data.
When scanning for cardholder data, it is just as important to scan where you think there may be cardholder data as where you would not expect there to be cardholder data. We quite often find cardholder data including recycle bins, application log files, database tables in the wrong field, and even PowerPoint presentations!
Protect Your Web Application
PCI provides two options for how you can protect your web application in Requirement 6.6. The two options are:
Manual or automated application vulnerability security assessment tools or methods at least annually and after any changes OR
Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications to continually check all traffic.
The important thing to note in Requirement 6.6 is that it specifically states that the manual or automated security assessments are not the same as the vulnerability scans performed for Requirement 11.2.
Many of the companies that provide vulnerability scanning offer separate tools focusing on web application vulnerability scans. And these services can be added on fairly easily. Once you find a service that can check for common web application vulnerability (e.g. OWASP-type vulnerabilities), it’s a matter of scheduling your scans and creating a process for fixing vulnerabilities that are identified.
The biggest challenge in Requirement 6.6 is that it requires testing after any change. Depending on your release cycle, this may be several times a day, once a month, or even less frequently. The important thing is to ensure that changes to your web application are aligned with scheduling scans. We recommend aligning the scans with your release to UAT or pre-production and then running the scans again after the release to production.
To round out the process, ensure that there is a process to get information from the web application vulnerability scans to your developers so that they can fix any issues before the change is pushed to production.
Web application scans need to be run against any external-facing web application.
Wireless Networks
Much like Requirement 6.6, Requirement 11.1 offers two ways that you can approach identifying any rogue wireless networks or devices in your network:
Wireless scanning
Automated monitoring (for example, wireless IDS/IPS, NAC, etc.)
These scans need to be carried out even if you do not have any in-scope wireless networks in your environment and needs to be carried out across all of your in-scope locations (including offices and data centres). Some data centres provide rogue wireless scanning as part of their Attestation of Compliance (AoC), but make sure that Requirement 11.1 is included in the scope of the services or you will need to ensure there is a process to complete this scanning yourself.
As part of the scanning process, the goal is to understand what “normal” looks like. So getting a baseline understanding and working from there to identify things that change and identifying criteria to understand what is suspicious will help you streamline your manual processes.
Internal and External Vulnerability Scanning
PCI requires that internal (Req. 11.2.1) and external (Req. 11.2.2) vulnerability scanning are carried out at least quarterly and after significant changes.
Your external vulnerability scanning must be carried out using an Approved Scanning Vendor. Make sure that you check that your vendor is on the list of ASVs on the PCI website.
Internal vulnerability scanning does not have to be carried out by an ASV, but many of the ASVs offer both internal and external scanning tools which can make the process easier than running multiple tools.
Scans and Re-Scans
The first thing you should do is make sure that you are scanning everything that needs to be scanned.
For external scanning, this means scanning any external interface that has the ability to affect the security of your in-scope environment. This means that aside from scanning the IP address for your payment page (or redirect page, etc.), you should may also need to be including things such as:
VPN connections
Externally accessible management services
VoIP services
Mail servers
etc.
We often see that supporting services get missed in external vulnerability scans.
For internal vulnerability scans, you need to ensure that they cover all of your in-scope environment including the CDE, your management zones, and potentially even workstations that are in-scope.
It’s not enough to just scan your environment once per quarter though. You need to make sure that you achieve a passing scan each quarter. You also need to be able to show that you are running (and passing) internal and external vulnerability scans after any significant changes.
For external scans, make sure that there is a process to get an attested scan each time you run the scan (at least quarterly). We recommend that scans are run monthly in case vulnerabilities are identified that need to be fixed. This gives you the longest possible timeframe to fix the vulnerabilities and still get a passing scan with in the quarter (90 days).
For internal vulnerability scans, the scanning process does not include an attestation process. So you need to make sure that as part of the scans, all the “High” and “Critical” vulnerabilities are addressed as well as vulnerabilities that do not result in an automatic failure. There may also be other vulnerabilities that you as an organisation want to address but that do not fall into either of these categories.
With internal vulnerability scans, the process of managing “false positives” is managed internally and you need to ensure that any false positives are recorded and actioned so that when your QSA reviews the results, they understand the findings (especially if there are vulnerabilities present which result in a failed internal vulnerability scan).
PCI does understand though that sometimes it may take multiple vulnerability scans to get a passing scan. Therefore, they set out clear guidance in FAQ 1152 for what is needed to meet the quarterly scan requirement:
Scans of all in-scope systems were performed for each quarterly period, and all in-scope systems are covered by the entity’s scan-remediate-rescan processes.
Rescans were performed as necessary, and show that vulnerabilities identified in the initial quarterly scans have been remediated, for all affected systems, as part of the quarterly process.
The entity has processes in place to remediate currently identified vulnerabilities.
Repeated failing scans are not the result of poor remediation practices resulting in previously identified vulnerabilities not being properly addressed.
The last bullet point is probably one of the most important ones. A vulnerability should not be present on your scans quarter after quarter showing the same failing vulnerability on the same server as this would in most cases indicate a poor remediation processes.
What Happens if I Miss a Quarterly Scan?
The biggest question is always: what happens if a scan is missed or the requirements for a passing scan are not met? If your QSA is not able to get evidence of four passing scans in the last year, they will not be able to mark this requirement as in-place. In the worst case scenario, this could mean that you could be non-compliant for several quarters while the requirement for passing scans is met.
This is why it is important to ensure that you:
Schedule and automatically run scans more frequently than quarterly.
Regularly review the findings of these scans
Have a clear remediation process in place
Regularly perform re-scans until the failing vulnerabilities are fixed.
Merchants with EFTPOS terminals have a set of requirements specific to card-present transaction security. That’s because card-skimming can happen anywhere, and it even happens in New Zealand! In this article, we want to help you understand how to protect the devices that your customers interact with to pay you.
Know Your Devices
PCI requires that you keep an inventory of all your devices that includes:
Manufacturer, make, and model
Physical location
Unique identifier (such as the serial number)
This basic information helps you understand what should be in your environment and provides you with the foundation to be able to know when there is something that doesn’t belong.
Secure Your Devices
Once you know what devices are in your store(s), the next thing to do is to take steps to secure the devices. This can be done through physical security controls or monitoring. Some examples of ways you can secure your devices include:
Making sure it is difficult to swap or remove cables by enclosing them away from customers.
Physically or logically locking down any network ports that the device plugs into.
Monitoring for tampering via CCTV (be careful that you aren’t accidentally collecting card numbers or PINs on your video)
Regularly checking devices for tampering.
Teach Your Staff
Your sales staff are the most important part of making sure that terminals are secured. But they can’t do this unless they understand how to tell if terminals have been tampered with. A terminal can be replaced faster than you think!
To understand if your devices have been tampered with, you need to understand what the device is expected to look like in its original state. This is where knowing about the types of devices you have becomes useful.
For each type of device, document what the expected “good state” of the device should be and what steps need to be checked by the person doing the regular inspections of the device. Examples of things that people should check for may include:
Does it match the expected make, model, and serial number or other unique identifier?
Is anything loose?
Had anything been added that wasn’t there last time?
Are there any unexpected scratches or marks that might be indicative of tampering?
It only takes seconds for someone to replace a device, but if your staff know what to look for and what to be aware of, this will help keep your devices secure.
Regular training is important for everyone, especially people who interact with customers on a daily basis since they’re the most likely to come into contact with cardholder data.
Understand how often staff change or leave roles to understand how often you need to do the training. Common things that training should cover include:
How to check devices.
What to do if someone wants to access the device (e.g. they ask to repair or replace it).
What kinds of suspicious behaviour to look for.
How to report anything that could be suspicious and who to report it to.
What to do with lost cards to keep them secure.
How Often Should You Check Your Devices?
This depends a lot on where they are. For example, if your devices are unattended, you might want to check them more frequently. However, if your devices are attended, you might want to make sure that your staff do a quick check at the start of any shift and a more detailed check at a lower frequency. Whatever you decide is right for your business, make it easy for staff to know what to look for and record what they have seen!
More Information
The PCI SSC publishes lots of resources for small businesses and retailers. Some of these documents include:
The Payment Card Industry Data Security Standard (PCI DSS) is a set of twelve high-level requirements which all merchants and service providers who take card payments or who manage systems that are involved in transactions are required to follow.
PCI DSS has high-level requirements and detailed testing requirements that need to be carried out in order to show compliance with the standard. This document covers the high-level requirements.
The Twelve PCI DSS Requirements
Requirement 1: As part of Requirement 1, you need to ensure that all of your firewalls are maintained and that they are configured to only allow the traffic which is required to sensitive parts of your network.
Requirement 2: Requirement 2 focuses on how you ensure that your servers, firewalls, and other devices that are used in your environment are configured securely.
Requirement 3: The focus in Requirement 3 is on protecting cardholder data. Cardholder data needs to be protected during all parts of the transaction process. This means that when it’s stored, it needs to be protected. Finding out locations of clear-text cardholder data through tools such as card-scanning can help you find cardholder data that you do not need and help you define your cardholder data environment.
Requirement 4: Requirement 4 focuses on protecting cardholder data when it is being transmitted over the internet. This means that cardholder data needs to be protected when it’s sent from the customer, when it’s sent to the payment gateway, and if you’re using a cloud service, you should protect your internal data too since it might be going over out of your control without your knowledge.
Requirement 5: Requirement 5 is all about anti-virus software and making sure it is configured securely. While not all systems can support anti-virus, we recommend installing it wherever it is supported.
Requirement 6: Requirement 6 covers two areas: vulnerability management and secure development.
Vulnerability management in Requirement 6 is about ensuring that you are regularly identifying threats to your systems, installing patches, and that all changes to systems are documented.
Secure development in Requirement 6 is about ensuring that you follow good development practices, such as having a separation of duties, ensuring there are separate environments, and making sure that all code is developed securely and tested.
Requirement 7: This requirement is all about managing the users who have access to your systems and making sure that people only have the minimum level of access they need to do their job.
Requirement 8: Requirement 8 is about making sure that users are authenticating securely. This means enforcing strong passwords and using multi-factor authentication. It also looks at how people access your databases where cardholder data is stored.
Requirement 9: Physical security is covered Requirement 9. This means making sure that any paper with cardholder data is stored securely and that anyone visiting sensitive areas is identified and approved for access. This requirement also covers the security of your data centres.
Requirement 10: Requirement 10 focuses on the security logs and monitoring of your systems. Making sure that you have logs and are regularly reviewing them is vital to being able to proactively identify security incidents.
Requirement 11: Requirement 11 focuses on more security testing, including doing regular scans to identify vulnerabilities and getting your systems tested by an organisation that specialises in penetration testing.
Requirement 12: Finally, Requirement 12 covers the policy and governance side of PCI DSS. Along with policies it includes user education and service provider management to make sure that third parties aren’t affecting your PCI DSS and security.
