If you store, process or transmit Visa Inc., MasterCard Inc., American Express Co., Discover or JCB International Co. credit cards in any fashion, you have an obligation to comply with the Payment Card Industry Data Security Standard (PCI DSS). The size of your business does not matter. If you accept credits from any of these six PCI members, through a merchant bank, you signed a contract. In your contract with your merchant bank you agreed to comply with PCI DSS. If you use a credit card from one of these six PCI members, you have agreed to do business with only PCI DSS compliant service providers. If you are a service provider who passes credit card information (has no merchant bank contract), they should not do business with you if you do not comply with PCI DSS.
Don’t fight it; comply with the PCI DSS standard. The standard was written to define a set of best practices. PCI DSS is not meant to be an oppressive burden upon businesses. After all, the credit card industry wants you to continue to accept credit cards. PCI DSS is not meant to be merely symbolic, either. The credit card industry does not want credit card crimes and identity theft to lead to legislation that defines how credit cards are to be handled. The credit card industry is demonstrating that it can address problems without legislation. The credit card industry is performing self-regulation.
The PCI DSS 2.0 standard (28-Oct-2010) is 75 pages of detailed requirements. Some requirements will not apply to you. PCI DSS 3.0 can be expected in November of 2013.
Do not confuse “compliance with PCI DSS” with “achieving security.” Credit card industry self-regulation defines a minimal “no excuses” set of expectations. “Security” is an abstraction which must be clarified in order to establish mutual expectations and trust. Abstractions must be clarified when creating an enforceable contract. “Compliance with ISO 27001” is a closer approximation to “achieving security.”
PCI DSS has nothing to say about information availability, for example. PCI DSS focus is upon information confidentiality.
You may wish to visit the Self-Assessment Questionnaire (SAQ) at this point to see what you will need to know.
Do I need a QSA when I complete the SAQ? That is, when filling out the Self-Assessment Questionaire (SAQ) do I need to hire a Qualified Security Assessor (QSA)? No. It is still a good idea to find a QSA company with QSAs. PCI DSS standard is occasionally revised and interpretations are clarified. It is not a simple matter to create unambiguous contract terms. PCI DSS revisions modify your contract without your knowledge. A QSA is not required. (There is no such thing as a free-lance, independent QSA. Check that the person assigned to you has current credentials [pdf].)
PCI DSS outline
Focus area 1: Build and maintain a secure network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
For example, a database which contains credit card information must be in an “internal network zone” and NOT your DMZ, to comply with requirement 1.3.7.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Focus area 2: Protect cardholder data
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Focus area 3: Maintain a vulnerability management program
Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications
Focus area 4: Implement strong access control measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data
Focus area 5: Regularly monitor and test networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes
Focus area 6: Maintain an information security policy
Requirement 12: Maintain a policy that addresses information security.
Note that policies must be enforced. Specifically, do not rely on a signed acceptable use policy. If acceptable use policy violations are tolerated, this will nullify any signed acceptable use policy.
That’s the gist of 74 pages, but you need to review the 74 pages and be clear about the details, such as what sufficient encryption would be.
In addition to these 74 pages, you also need to know what reporting your merchant bank requires to assure you are PCI DSS compliant. This varies, depending upon the credit card and the size of your business.
For example,
over 6,000,000 Visa transactions (of any kind) per year: you must complete an annual on-site assessment by a Qualified Security Assessor and conduct quarterly network scans using an Approved Scanning Vendor. These are also the requirements if you have had a security breach. (Level 1 merchants)
MasterCard – similar requirements if you make over 1,000,000 transactions (Level 1)
1,000,000 to 6,000,000 Visa transactions (of any kind): same as above, except an annual self-assessment substitutes for the annual on-site assessment by a Qualified Security Assessor. 20,000 to 6,000,000 e-commerce transactions also have these reporting requirements (annual self-assessment, and quarterly network scans). (Level 2, 3 and 4A merchants)
MasterCard – similar requirements if you make under 1,000,000 transactions (Level 2)
fewer than 1,000,000 Visa transactions or fewer than 20,000 e-commerce transactions have no reporting requirements. An annual self-assessment and quarterly network scans are recommended. (Level 4B merchants)
This won’t be that bad now, will it?
What PCI is not
See Ten Common Myths of PCI DSS, from the PCI Security Standards Council.
Preparing enterprise Wi-Fi networks for PCI compliance by John Kindervag, Forrester Research, fleshes out some details:
PCI DSS 1.2: Guidance for wireless networks
- Basic network security
- Document the wireless network in a network drawing.
- A stateful firewall between wired and wireless networks.
- Firewall rules restrict access between wireless networks and sensitive servers.
- No vendor-supplied passwords.
- Wireless log data must be sent to a PCI-compliant logging server (syslog).
- Encryption
- Phase out WEP by June 30, 2010.
- Use strong encryption such as WPA2, using AES 128-bit encryption.
- Regular scanning
- Scan for rogue access points and wireless devices.
- Manual scanning is acceptable, but not practical.
- Provide secure wireless guest access
- The wireless gateway should capture outbound HTTP traffic and force users to comply with policy.
There is more to the article, including advice about reviewing your implementation and a reminder that you want to separate the systems involved with PCI data from systems without PCI data. You do this because the PCI audits can be simpler, not because your security should be less for systems not involved with PCI data. Implement the ability to demonstrate that no PCI data exists on other environments.
For network segmentation guidance, see page 5 of the PCI DSS Requirements and Security Assessment Procedures
At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. However, the adequacy of a specific implementation of network segmentation is highly variable and dependent upon such things as a given network’s configuration, the technologies deployed, and other controls that may be implemented.
Note that neither segmentation nor encryption is required. See, for example, The ‘security standards dilemma’: Network segmentation and PCI Compliance. Protection of personally identifiable information from disclosure, corruption, or modification is your goal, which incidentally (and not accidentally) achieves PCI compliance.
Segmentation, the segregation and isolation of payment systems through firewalls, VLANs or physical separation, enables you to limit the scope of the PCI audit. This allows you to control the scope and cost of the audit. In scope hosts will require anti-virus software, file integrity monitoring, log monitoring, patch management, vulnerability scanning, and policies for each of the above. A host IPS, data leakage prevention and whole disk encryption are not required but should be considered.
Security Information Management (SIM) or Security Event Management (SEM) software is not required, but is difficult to avoid since PCI requires daily event log reviews.
Two-factor authentication is not required by PCI, but remote access without two-factor authentication is penny-wise, pound-foolish. Due care.
Helpful information is available through:
- The PCI Knowledge Base
- The Aegenis Group (pcianswers.com)
- The Legal Implications, Risks and Problems of the PCI Data Security Standard
PCI explains how merchants can securely accept mobile payments [pdf]
Aggressive Virus Defense 