This post presents How to comply with PCI DSS. This article is a summary from of the pcisecuritystandards.org website. With the following link:
For more info please refer to pcisecuritystandards.org
We recommend you that before continuing, read this post.
Each payment card brand maintains its own separate compliance enforcement programs and it has defined specific requirements for compliance validation and reporting, such as provisions for performing self-assessments and when to engage a QSA. OK, there are three concepts:
- Qualified Security Assessor (QSA): It is a person who has been certified by the PCI Security Standards Council to audit merchants for Payment Card Industry Data Security Standard (PCI DSS) compliance. QSAs are employed as impartial third parties during PCI-compliance audits of Level 1 merchants (those who process over 6 million Visa transactions a year). During the audit process, a QSA fills out a Report on Compliance (ROC) that verifies the merchant’s compliance with PCI DSS. The ROC is sent to the merchant’s acquiring bank, which then sends it to the appropriate credit card company for compliance verification. (Source: techtarget.com )
- Report on Compliance (ROC): A ROC tests the standards that are in place to protect the credit card information. A PCI ROC is required for all Level 1 Merchants. A Level 1 Merchant is a retailer that has more than 6 million annual transactions with Visa and/or Master card. (Source: fortytwo.nl)
- Attestation of Compliance (AOC): It is a signed document evidencing compliance with PCI DSS. It is a form for merchants and service providers to attest to the results of a PCI DSS assessment, as documented in the Self-Assessment Questionnaire or Report on Compliance. (Source: lawinsider.com)
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. SAQ or ROC), including documentation of all compensating controls.
- Attest: Complete the 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.
The QSA will:
- Verify all technical information given by merchant or service provider
- Use independent judgment to confirm the standard has been met
- Provide support and guidance during the compliance process
- Be onsite for the duration of the assessment as required
- Adhere to the PCI DSS Security Assessment Procedures
- Validate the scope of the assessment
- Evaluate compensating controls
- Produce the final report
The QSA you select should have solid understanding of your business and have experience in assessing the security of similar organizations. 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.
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.
- 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.
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 (CDE: Cardholder Data Environment. The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data)
- 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.
- Retain documentation that shows how PCI DSS scope was determined.
—————————————————–
This article is a summary from of the pcisecuritystandards.org website. With the following link:
For more info please refer to pcisecuritystandards.org
—————————————————–
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 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.
- 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.
- Quarterly submission of a report for network scanning may also be required.
- Individual payment card brands may require submission of other documentation.
The template for an entity’s annual Report on Compliance is available on the PCI SSC Website, and includes the following:
- Contact Information and Report Date
- Executive Summary (description of entity’s payment card business; high level network diagram)
- Description of Scope of Work and Approach Taken
- 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)
- Quarterly Scan Results (summary of four most recent ASV scan results)
- Findings and Observations (including explanations of all N/A responses and validation of all compensating controls)
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.
Examples of best practices for how to incorporate PCI DSS into BAU activities include (but are not limited to):
- Monitoring of security controls
- 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.
- 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.
————————-
Sources:
1- This article is a summary from of the pcisecuritystandards.org website. With the following link:
For more info please refer to pcisecuritystandards.org
2- searchsecurity.techtarget.com
3- fortytwo.nl
