PCI DSS applies to merchants and other entities that store, process, and/or transmit cardholder data. While the Council is responsible for managing the data security standards, each payment card brand maintains its own separate compliance enforcement programs. Each payment card brand has defined specific requirements for compliance validation and reporting, such as provisions for performing selfassessments and when to engage a QSA. Depending on an entity’s classification or risk level (determined by the individual payment card brands), processes for compliance usually follow these steps:
- Scope – determine which system components and networks are in scope for PCI DSS
- Assess – examine the compliance of system components in scope following the testing procedures for each PCI DSS requirement
- Report – assessor and/or entity completes required documentation (e.g. Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)), including documentation of all compensating controls
- Attest – complete the appropriate Attestation of Compliance (AOC)
- Submit – submit the SAQ, ROC, AOC and other requested supporting documentation such as ASV scan reports to the acquirer (for merchants) or to the payment brand/requestor (for service providers)
- Remediate – if required, perform remediation to address requirements that are not in place, and provide an updated report
The QSA you select should have solid understanding of your business and have experience in assessing the security of similar organizations. That knowledge helps the QSA to understand business sectorspecific nuances of securing cardholder data under PCI DSS. Also, look for a good fit with your company’s culture. The assessment will conclude whether you have met the requirements– but the QSA may also work with your organization to help you understand how to achieve and maintain compliance on a day-to-day basis. Many QSAs also can provide additional security-related services such as ongoing vulnerability assessment and remediation. A list of QSAs is available at www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors.
Choosing an Approved Scanning Vendor
An Approved Scanning Vendor (ASV) is a data security firm using a scanning solution to determine whether or not the customer meets the PCI DSS external vulnerability scanning requirement. ASVs are qualified by the PCI Security Standards Council to perform external network and system scans as required by the PCI DSS. An ASV may use its own software or an approved commercial or open source solution. ASV solutions must be non-disruptive to customers’ systems and data – they must never cause a system reboot, or interfere with or change domain name server (DNS) routing, switching, or address resolution. Root-kits or other software must not be installed unless part of the solution and pre-approved by the customer. Tests not permitted by the ASV solution include denial of service, buffer overflow, brute force attack resulting in a password lockout, or excessive usage of available communication bandwidth. An ASV scanning solution includes the scanning procedures and tool(s), the associated scanning report, and the process for exchanging information between the scanning vendor
and the scan customer. ASVs may submit compliance reports to the acquiring institution on behalf of a merchant or service provider, if agreed by the ASV and their customer. A list of ASVs is available at www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors.
Scope of PCI DSS Requirements
The first step of PCI DSS is to accurately determine the scope of the environment. The scoping process includes identifying all system components that are located within or connected to the cardholder data environment. The cardholder data environment is comprised of people, processes, and technology that
handle cardholder data or sensitive authentication data. System components include network devices (both wired and wireless), servers, computing devices, and applications. Virtualization components, such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors, are also considered system components within PCI DSS. Scoping must occur at least annually and prior to the annual assessment. Merchants and other entities
must identify all locations and flows of cardholder data, and identify all systems that are connected to or if compromised could impact the CDE (e.g. authentication servers) to ensure all applicable system components are included in scope for PCI DSS. All types of systems and locations should be considered
as part of the scoping process, including backup/recovery sites and fail-over systems. Entities should confirm the accuracy of the defined CDE by performing these steps:
• Identify and document the existence of all cardholder data in the environment, to verify that no cardholder data exists outside of the currently defined cardholder data environment (CDE).
• Once all locations of cardholder data are identified and documented, verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).
• Consider any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. If data is identified that is not currently included in the CDE, such data should be securely deleted, migrated/consolidated into the currently defined CDE, or the CDE redefined to include these data.
• Retain documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity.
Network Segmentation
Scope can be reduced with the use of segmentation, which isolates the cardholder data environment from the remainder of an entity’s network. Reduction of scope can lower the cost of the PCI DSS assessment, lower the cost and difficulty of implementing and maintaining PCI DSS controls, and reduce risk for the entity. To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE. For more information on scoping, see the PCI DSS “Network Segmentation” section and Appendix D: Segmentation and Sampling of Business Facilities/System Components.
Sampling of Business Facilities and System Components
Sampling is an option for assessors to facilitate the assessment process where there are large numbers of system components. While it is acceptable for an assessor to sample systems as part of their review of an entity’s PCI DSS compliance, it is not acceptable for an entity to apply PCI DSS requirements to only a
sample of their CDE, or for an assessor to only review a sample of PCI DSS requirements for compliance. The assessor may independently select representative samples of business facilities and system components to assess the entity’s compliance with PCI DSS requirements. Sampling is not required by PCI DSS. Sampling does not reduce scope of the cardholder data environment or the applicability of PCI DSS requirements. If sampling is used, each sample must be assessed against all applicable PCI DSS requirements. Samples must be sufficiently large to provide the assessor with assurance that controls are implemented as expected. For more information on sampling, see PCI DSS section For Assessors: Sampling of Business Facilities/System Components and Appendix D: Segmentation and Sampling of Business Facilities/System Components.
Use of Third Party Service Providers/Outsourcing
A service provider or merchant may use a third-party service to store, process, or transmit cardholder data on their behalf, or to manage CDE components. Parties should clearly identify the services and system components that are included in the scope of the service provider’s annual onsite PCI DSS assessment, the specific PCI DSS requirements covered by the service provider, and any requirements which are the responsibility of the service provider’s customers to include in their own PCI DSS reviews. If the third party undergoes their own PCI DSS assessment, they should provide sufficient evidence to their customers to verify that the scope of the service provider’s PCI DSS assessment covered the services applicable to the customer and that the relevant PCI DSS requirements were examined and determined to be in place. The service provider Attestation of Compliance includes a table that summarizes PCI DSS requirements covered and the specific service(s) assessed, and can be provided to customers as evidence of the scope of a service provider’s PCI DSS assessment. However, the specific type of evidence provided by the service provider to their customers will depend on the agreements/contracts in place between those parties. Merchants and service providers must manage and monitor the PCI DSS compliance of all associated third-party service providers with access to cardholder data.
Using the Self-Assessment Questionnaire (SAQ)
The “SAQ” is a validation tool for merchants and service providers to report the results of their PCI DSS self-assessment, if they are not required to submit a Report on Compliance (ROC). The SAQ includes a series of yes-or-no questions for each applicable PCI DSS requirement. If an answer is no, the organization may be required to state the future remediation date and associated actions. There are different SAQs available to meet different merchant environments. If you are not sure which SAQ would apply to you, contact your acquiring bank or payment card brand for assistance. The PCI DSS SAQ Instructions and Guidelines document provides more details on each SAQ type (see www.pcisecuritystandards.org/document_library?category=saqs#results).
Reports are the official mechanism by which merchants and other entities report their PCI DSS
compliance status to their respective acquiring financial institutions or payment card brand. Depending
on payment card brand requirements, merchants and service providers may need to submit an SAQ for
self-assessments, or a Report on Compliance for on-site assessments. Quarterly submission of a report for
network scanning may also be required. Finally, individual payment card brands may require submission
of other documentation; see their web sites for more information.
Information Contained in PCI DSS Report on Compliance
The template for an entity’s annual Report on Compliance is available on the PCI SSC Website, and
includes the following:
1. Contact Information and Report Date
2. Executive Summary (description of entity’s payment card business; high level network diagram)
3. Description of Scope of Work and Approach Taken (description of how the assessment was made, environment, network segmentation used, details for each sample set selected and tested, wholly owned or international entities requiring compliance with PCI DSS, wireless networks or applications that could impact security of cardholder data, version of PCI DSS used to conduct the assessment)
4. Details about Reviewed Environment (diagram of each network, description of cardholder data environment, list of all hardware and software in the CDE, service providers used, third party payment applications, individuals interviewed, documentation reviewed, details for reviews of managed service providers)
5. Quarterly Scan Results (summary of four most recent ASV scan results)
6. Findings and Observations (detailed findings on each requirement and sub-requirement, including explanations of all N/A responses and validation of all compensating controls)
Implementing PCI DSS into Business-As-Usual Processes
To ensure security controls continue to be properly implemented, PCI DSS should be implemented into business-as-usual (BAU) activities as part of an entity’s overall security strategy. This enables an entity to monitor the effectiveness of its security controls on an ongoing basis, and maintain its PCI DSS compliant
environment in between PCI DSS assessments. Examples of best practices for how to incorporate PCI DSS into BAU activities include (but are not limited to):
- Monitoring of security controls to ensure they are operating effectively and as intended.
- Ensuring that all failures in security controls are detected and responded to in a timely manner.
- Reviewing changes to the environment (for example, addition of new systems, changes in system or network configurations) prior to completion of the change to ensure PCI DSS scope is updated and controls are applied as appropriate.
- Changes to organization structure (for example, a company merger or acquisition) resulting in a formal review of the impact to PCI DSS scope and requirements.
- Performing periodic reviews and communications to confirm that PCI DSS requirements continue to be in place and personnel are following secure processes.
- Reviewing hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS, and remediating shortcomings as appropriate. Entities may also consider implementing separation of duties for their security functions so that security and/or audit functions are separated from operational functions.
Note: For some entities, these best practices are also requirements to ensure ongoing PCI DSS compliance.
All organizations should consider implementing these best practices into their environment, even where the
organization is not required to validate to them.
People also ask this Questions
- What is a defense in depth security strategy how is it implemented?
- What is AWS Solution Architect?
- What is the role of AWS Solution Architect?
- Is AWS Solution Architect easy?
- What is AWS associate solutions architect?
- Is AWS Solutions Architect Associate exam hard?
Infocerts, 5B 306 Riverside Greens, Panvel, Raigad 410206 Maharashtra, India
Contact us – https://www.infocerts.com
