Brstjjy

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes.

The PCI Standard is mandated by the card brands and administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around cardholder data to reduce credit card fraud. Validation of compliance is performed annually or quarterly,^[1] either by an external Qualified Security Assessor (QSA) or by a firm specific Internal Security Assessor (ISA) that creates a Report on Compliance for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes.^{[2][promotional or fringe source?][3]}

History

Five different programs had been started by card companies:

• 
  Visa's Cardholder Information Security Program
  


• 
  MasterCard's Site Data Protection


• 
  American Express's Data Security Operating Policy


• 
  Discover's Information Security and Compliance


• the JCB's Data Security Program

The intentions of each were roughly similar: to create an additional level of protection for card issuers by ensuring that merchants meet minimum levels of security when they store, process, and transmit cardholder data. To cater out the interoperability problems among the existing standards, the combined effort made by the principal credit card organizations resulted in the release of version 1.0 of PCI DSS in December 2004. PCI DSS has been implemented and followed across the globe.^{[2][promotional or fringe source?]}

The Payment Card Industry Security Standards Council (PCI SSC) was then formed and these companies aligned their individual policies to create the PCI DSS.^{[citation needed]} MasterCard, American Express, Visa, JCB International and Discover Financial Services established the PCI SSC in September 2006 as an administration/governing entity which mandates the evolution and development of PCI DSS. Independent/private organizations can participate in PCI development after proper registration. Each participating organization joins a particular SIG (Special Interest Group) and contributes to the activities which are mandated by the SIG.^{[2][promotional or fringe source?]}

The following versions of the PCI DSS have been made available:^{[2][promotional or fringe source?]}

• 1.0 was released on December 15, 2004.


• 1.1 in September 2006 provide clarification and minor revisions.


• 1.2 was released on October 1, 2008. It enhanced clarity, improved flexibility, and addressed evolving risks and threats.


• 1.2.1 in August 2009 made minor corrections designed to create more clarity and consistency among the standards and supporting documents.


• 2.0 was released in October 2010.


• 3.0 was released in November 2013 and was active from January 1, 2014 to June 31, 2015.


• 3.1 was released in April 2015, and has been retired since October 31, 2016.


• 3.2 was released in April 2016, and it will be retired on December 31, 2018.


• 3.2.1 was released in May 2018.

Requirements

The PCI Data Security Standard specifies twelve requirements for compliance, organized into six logically related groups called "control objectives". These six groups are:^{[2][promotional or fringe source?]}

1. Build and Maintain a Secure Network and Systems


2. Protect Cardholder Data


3. Maintain a Vulnerability Management Program


4. Implement Strong Access Control Measures


5. Regularly Monitor and Test Networks


6. Maintain an Information Security Policy

Each version of PCI DSS has divided these six requirements into a number of sub-requirements differently, but the twelve high-level requirements have not changed since the inception of the standard. Each requirement/sub-requirement is additionally elaborated into three sections.^{[2][promotional or fringe source?]}

1. Requirement Declaration: It defines the main description of the requirement. The endorsement of PCI DSS is done on the proper implementation of the requirements.


2. Testing Processes: The processes and methodologies carried out by the assessor for the confirmation of proper implementation.


3. Guidance: It explains the core purpose of the requirement and the corresponding content which can assist in the proper definition of the requirement.

The 12 requirements for building and maintaining a secure network and systems can be summarized as follows:^{[4][promotional or fringe source?]}

1. Installing and maintaining a firewall configuration to protect cardholder data. The purpose of a firewall is to scan all network traffic, block untrusted networks from accessing the system.


2. Changing vendor-supplied defaults for system passwords and other security parameters. These passwords are easily discovered through public information and can be used by malicious individuals to gain unauthorized access to systems.


3. Protecting stored cardholder data. Encryption, hashing, masking and truncation are methods used to protect card holder data.


4. Encrypting transmission of cardholder data over open, public networks. Strong encryption, including using only trusted keys and certifications reduces risk of being targeted by malicious individuals through hacking.


5. Protecting all systems against malware and performing regular updates of anti-virus software. Malware can enter a network through numerous ways, including Internet use, employee email, mobile devices or storage devices. Up-to-date anti-virus software or supplemental anti-malware software will reduce the risk of exploitation via malware.


6. Developing and maintaining secure systems and applications. Vulnerabilities in systems and applications allow unscrupulous individuals to gain privileged access. Security patches should be immediately installed to fix vulnerability and prevent exploitation and compromise of cardholder data.


7. Restricting access to cardholder data to only authorized personnel. Systems and processes must be used to restrict access to cardholder data on a “need to know” basis.


8. Identifying and authenticating access to system components. Each person with access to system components should be assigned a unique identification (ID) that allows accountability of access to critical data systems.


9. Restricting physical access to cardholder data. Physical access to cardholder data or systems that hold this data must be secure to prevent the unauthorized access or removal of data.


10. Tracking and monitoring all access to cardholder data and network resources. Logging mechanisms should be in place to track user activities that are critical to prevent, detect or minimize impact of data compromises.


11. Testing security systems and processes regularly. New vulnerabilities are continuously discovered. Systems, processes and software needs to be test frequently to uncover vulnerabilities that could be used by malicious individuals.


12. Maintaining an information security policy for all personnel. A strong security policy includes making personnel understand the sensitivity of data and their responsibility to protect it.

Updates and supplemental information

The PCI SSC(Payment Card Industry Security Standards Council) has released several supplemental pieces of information to clarify various requirements. These documents include the following ^{[2][promotional or fringe source?]}

• Information Supplement: Requirement 11.3 Penetration Testing


• Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified


• Navigating the PCI DSS - Understanding the Intent of the Requirements


• 
  "Information Supplement: PCI DSS Wireless Guidelines" (PDF). August 26, 2011..mw-parser-output cite.citation{font-style:inherit}.mw-parser-output q{quotes:"""""""'""'"}.mw-parser-output code.cs1-code{color:inherit;background:inherit;border:inherit;padding:inherit}.mw-parser-output .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-lock-limited a,.mw-parser-output .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration{color:#555}.mw-parser-output .cs1-subscription span,.mw-parser-output .cs1-registration span{border-bottom:1px dotted;cursor:help}.mw-parser-output .cs1-hidden-error{display:none;font-size:100%}.mw-parser-output .cs1-visible-error{font-size:100%}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration,.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left,.mw-parser-output .cs1-kern-wl-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right,.mw-parser-output .cs1-kern-wl-right{padding-right:0.2em}
  


• PCI DSS Applicability in an EMV Environment ^{[5][promotional or fringe source?]}
  


• Prioritized Approach for PCI DSS


• Prioritized Approach Tool


• PCI DSS Quick Reference Guide


• PCI DSS Virtualization Guidelines


• PCI DSS Tokenization Guidelines


• PCI DSS 2.0 Risk Assessment Guidelines


• The lifecycle for Changes to the PCI DSS and PA-DSS


• Guidance for PCI DSS Scoping and Segmentation

Validation of compliance

Compliance validation involves the evaluation and confirmation that the security controls & procedures have been properly implemented as per the policies recommended by PCI DSS. In short, the PCI DSS, security validation/testing procedures mutually as compliance validation tool. A PCI DSS assessment has the following entities. ^{[6][promotional or fringe source?][7]}

Qualified Security Assessor (QSA)

A Qualified Security Assessor is an individual bearing a certificate that has been provided by the PCI Security Standards Council. This certified person can audit merchants for Payment Card Industry Data Security Standard (PCI DSS) compliance. QSAs are the independent groups/entities which have been certified by PCI SSC for compliance confirmation in organization procedures. The confirmation just assigns that a QSA has tended to all the separate prerequisites which are mandatory to do PCI DSS appraisals. ^{[6][promotional or fringe source?][7]}

Internal Security Assessor (ISA)

An Internal Security Assessor is an individual who has earned a certificate from the PCI Security Standards Company for their sponsoring organization. This certified person has the ability to perform PCI self-assessments for their organization. This ISA program was designed to help Level 2 merchants meet the new Mastercard compliance validation requirements.^[8] ISA certification empowers a worker to do an inward appraisal of his/her association and propose security solutions/ controls for the PCI DSS compliance. As the ISAs are upheld by the organization for the PCI SSC affirmation, they are in charge of cooperation and participation with QSAs.^{[6][promotional or fringe source?][7]}

Report on Compliance (ROC)

A Report on Compliance is a form that has to be filled by all level 1 merchants Visa merchants undergoing a PCI DSS (Payment Card Industry Data Security Standard) audit. The ROC form is used to verify that the merchant being audited is compliant with the PCI DSS standard. ROC confirms that policies, strategies, approaches & workflows are appropriately implemented/developed by the organization for the protection of cardholders against scams/frauds card-based business transactions. A template “ROC Reporting Template” available on PCI SSC site contains detailed guidelines about the ROC. ^{[6][promotional or fringe source?][7]}

Self-Assessment Questionnaire (SAQ)

The PCI DSS self-assessment questionnaires (SAQs) are validation tools intended to assist merchants and service providers report the results of their PCI DSS self-assessment.

The Self-Assessment Questionnaire is a set of Questionnaires documents that merchants are required to complete every year and submit to their transaction Bank. Another component of SAQ is Attestation of Compliance (AOC) where each SAQ question is replied based on the internal PCI DSS self-evaluation. Each SAQ question must be replied with yes or no alternative. In the event that a question has the appropriate response "no", at that point the association must highlight its future implementation aspects.^{[6][promotional or fringe source?][7]}

There are multiple types of SAQs for different PCI environments, ranging from A to D. It is crucial for merchants to figure out which type of SAQ suits their environment the best before going in to self-assessment.

Compliance versus validation of compliance

Although the PCI DSS must be implemented by all entities that process, store or transmit cardholder data, formal validation of PCI DSS compliance is not mandatory for all entities. Currently both Visa and MasterCard require merchants and service providers to be validated according to the PCI DSS. Visa also offers an alternative program called the Technology Innovation Program (TIP) that allows qualified merchants to discontinue the annual PCI DSS validation assessment. These merchants are eligible if they are taking alternative precautions against counterfeit fraud such as the use of EMV or Point to Point Encryption.

Issuing banks are not required to go through PCI DSS validation although they still have to secure the sensitive data in a PCI DSS compliant manner. Acquiring banks are required to comply with PCI DSS as well as to have their compliance validated by means of an audit.

In the event of a security breach, any compromised entity which was not PCI DSS compliant at the time of breach will be subject to additional card scheme penalties, such as fines.

Mandated compliance

Compliance with PCI DSS is not required by federal law in the United States. However, the laws of some U.S. states either refer to PCI DSS directly, or make equivalent provisions.

In 2007, Minnesota enacted a law prohibiting the retention of some types of payment card data subsequent to 48 hours after authorization of the transaction.^[9]

In 2009, Nevada incorporated the standard into state law, requiring compliance of merchants doing business in that state with the current PCI DSS, and shields compliant entities from liability.

In 2010, Washington also incorporated the standard into state law. Unlike Nevada's law, entities are not required to be compliant to PCI DSS, but compliant entities are shielded from liability in the event of a data breach.

Compliance and wireless LANs

In July 2009, the Payment Card Industry Security Standards Council published wireless guidelines for PCI DSS recommending the use of wireless intrusion prevention system (WIPS) to automate wireless scanning for large organizations. Wireless guidelines clearly define how wireless security applies to PCI DSS compliance. The guidelines were updated in August 2011 (Version 2.0).^[10]

These guidelines apply to the deployment of wireless LAN (WLAN) in Cardholder Data Environments, also known as CDEs. A CDE is defined as a network environment that stores, processes or transmits credit card data.

Wireless LAN and CDE classification

PCI DSS wireless guidelines classify CDEs into three scenarios depending on how wireless LANs are deployed.^[10]

• 
  No known WLAN AP inside or outside the CDE: The organization has not deployed any WLAN AP. In this scenario, three minimum scanning requirements (Sections 11.1, 11.4 and 12.9) of the PCI DSS apply.


• 
  Known WLAN AP outside the CDE: The organization has deployed WLAN APs outside the CDE. These WLAN APs are segmented from the CDE by a firewall. There are no known WLAN APs inside the CDE. In this scenario, three minimum scanning requirements (Sections 11.1, 11.4 and 12.9) of the PCI DSS apply.


• 
  Known WLAN AP inside the CDE: The organization has deployed WLAN APs inside the CDE. In this scenario, three minimum scanning requirements (Sections 11.1, 11.4 and 12.9), as well as six secure deployment requirements (Sections 2.1.1, 4.1.1, 9.1.3, 10.5.4, 10.6 and 12.3) of the PCI DSS apply.

Key sections of PCI DSS that are relevant for wireless security are classified and defined below.

Secure deployment requirements for wireless LANs

These secure deployment requirements apply to only those organizations that have a known WLAN AP inside the CDE. The purpose of these requirements is to deploy WLAN APs with proper safeguards.^[10]

• 
  Section 2.1.1 Change Defaults: Change default passwords, SSIDs on wireless devices. Enable WPA or WPA2 security.


• 
  Section 4.1.1 802.11i Security: Set up APs in WPA or WPA2 mode with 802.1X authentication and AES encryption. Use of WEP in CDE is not allowed after June 30, 2010.


• 
  Section 9.1.3 Physical Security: Restrict physical access to known wireless devices.


• 
  Section 10.5.4 Wireless Logs: Archive wireless access centrally using a WIPS for 1 year.


• 
  Section 10.6 Log Review: Review wireless access logs daily.


• 
  Section 12.3 Usage Policies: Develop usage policies to list all wireless devices regularly. Develop usage possible for the use of wireless devices.

Minimum scanning requirements for wireless LAN

These minimum scanning requirements apply to all organizations regardless of the type of wireless LAN deployment in the CDE. The purpose of these requirements is to eliminate any rogue or unauthorized WLAN activity inside the CDE.

• 
  Section 11.1 Quarterly Wireless Scan: Scan all sites with CDEs whether or not they have known WLAN APs in the CDE. Sampling of sites is not allowed. A WIPS is recommended for large organizations since it is not possible to manually scan or conduct a walk-around wireless security audit of all sites on a quarterly basis


• 
  Section 11.4 Monitor Alerts: Enable automatic WIPS alerts to instantly notify personnel of rogue devices and unauthorized wireless connections into the CDE.


• 
  Sectional 12.9 Eliminate Threats: Prepare an incident response plan to monitor and respond to alerts from the WIPS. Enable automatic containment mechanism on WIPS to block rogues and unauthorized wireless connections.

Risk management to protect cardholder data

Under PCI DSS’s requirement 3, merchants and financial institutions are implored to protect their clients’ sensitive data with strong cryptography. Non compliant solutions will not pass the audit.^[3] A typical risk management program can be structured in 3 steps:^{[11][promotional or fringe source?]}

1. Identify all known risks and record/describe them in a risk register. For example, hardware security modules (HSM) that are used in the cryptographic key management process could potentially introduce their own risks if compromised, whether physically or logically. HSMs create a root of trust within in the system. However, while it is unlikely, if the HSM is compromised, this could compromise the entire system.


2. Develop a risk management program is to analyze all identified risks. Included in this analysis should be a mix of qualitative and quantitative techniques to determine what risk treatment methods should be used to reduce the possibility of risks. For example, an organization might analyze the risk of using a cloud HSM versus a physical device that they use onsite.


3. Treat the risks in response to the risk analysis that was previously performed. For example, employing different treatments to protect client information stored in a cloud HSM versus ensuring security both physically and logically for an onsite HSM, which could include implementing controls or obtaining insurance to maintain an acceptable level of risk.

Continuous monitoring and review are part of the process of reducing PCI DSS cryptography risks. This includes maintenance schedules and predefined escalation and recovery routines when security weaknesses are discovered.^[11]

Controversies and criticisms

Visa and Mastercard impose fines for non-compliance.^{[12][promotional or fringe source?]}

Stephen and Theodora "Cissy" McComb, owners of Cisero’s Ristorante and Nightclub in Park City, Utah, were allegedly fined for a breach for which two forensics firms could not find evidence as having occurred:

"The PCI system is less a system for securing customer card data than a system for raking in profits for the card companies via fines and penalties. Visa and MasterCard impose fines on merchants even when there is no fraud loss at all, simply because the fines 'are profitable to them'."^{[citation needed]}

Michael Jones, CIO of Michaels' Stores, testified before a U.S. Congress subcommittee regarding the PCI DSS:

"(...the PCI DSS requirements...) are very expensive to implement, confusing to comply with, and ultimately subjective, both in their interpretation and in their enforcement. It is often stated that there are only twelve 'Requirements' for PCI compliance. In fact there are over 220 sub-requirements; some of which can place an incredible burden on a retailer and many of which are subject to interpretation."^{[citation needed]}

Others have suggested that PCI DSS is a step toward making all businesses pay more attention to IT security, even if minimum standards are not enough to completely eradicate security problems. For example, Bruce Schneier has spoken in favor of PCI DSS:

"Regulation—SOX, HIPAA, GLBA, the credit-card industry's PCI, the various disclosure laws, the European Data Protection Act, whatever—has been the best stick the industry has found to beat companies over the head with. And it works. Regulation forces companies to take security more seriously, and sells more products and services."^{[citation needed]}

PCI Council General Manager Bob Russo's responded to the objections of the National Retail Federation:

"[PCI is a structured] blend...[of] specificity and high-level concepts [that allows] stakeholders the opportunity and flexibility to work with Qualified Security Assessors (QSAs) to determine appropriate security controls within their environment that meet the intent of the PCI standards."^{[citation needed]}

Compliance and compromises

According to Visa Chief Enterprise Risk Officer Ellen Richey (2018):

"...no compromised entity has yet been found to be in compliance with PCI DSS at the time of a breach."^[13]

In 2008, a breach of Heartland Payment Systems, an organisation validated as compliant with PCI DSS, resulted in the compromising of one hundred million card numbers. Around this same time Hannaford Brothers and TJX Companies, also validated as PCI DSS compliant, were similarly breached as a result of the alleged coordinated efforts of Albert "Segvec" Gonzalez and two unnamed Russian hackers.^{[citation needed]}

Assessments examine the compliance of merchants and services providers with the PCI DSS at a specific point in time and frequently utilize a sampling methodology to allow compliance to be demonstrated through representative systems and processes. It is the responsibility of the merchant and service provider to achieve, demonstrate, and maintain their compliance at all times both throughout the annual validation/assessment cycle and across all systems and processes in their entirety. Although it could be that a breakdown in merchant and service provider compliance with the written standard was to blame for the breaches, Hannaford Brothers had received its PCI DSS compliance validation one day after it had been made aware of a two-month-long compromise of its internal systems. The failure of this to be identified by the assessor suggests that incompetent verification of compliance undermines the security of the standard.^{[citation needed]}

Other criticism lies in that compliance validation is required only for Level 1-3 merchants and may be optional for Level 4 depending on the card brand and acquirer. Visa's compliance validation details for merchants state that level 4 merchants compliance validation requirements are set by the acquirer, Visa level 4 merchants are "Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually". At the same time over 80% of payment card compromises between 2005 and 2007 affected Level 4 merchants; they handle 32% of transactions.^{[citation needed]}

See also

• Penetration test


• Vulnerability management


• Wireless LAN


• Wireless security

References

Further reading

• 
  Bhargav, Abhay (2014). PCI compliance : the definitive guide. Boca Raton, FL: CRC Press, Taylor and Francis. ISBN 9781439887417. OCLC 878262783.
  


• 
  Campbell, Tony (2016). Practical information security management : a complete guide to planning and implementation. United States: Apress. ISBN 9781484216859. OCLC 965719069.
  


• 
  Williams, Branden (2015). PCI compliance : understand and implement effective PCI data security standard compliance. Waltham, MA: Syngress. ISBN 9780128016510. OCLC 897934305.
  

External links

• Official PCI Security Standards Council Site