During our recent virtual seminar, PCI DSS 2.0: Why the latest update matters to you, experts Ed Moyle and Diana Kelley of SecurityCurve were unable to answer all of the PCI DSS questions they received during their live question-and-answer session. SearchSecurity.com has asked them to give brief responses to each of the unanswered questions, and we've published those questions and responses below to help you solve your unique PCI p...
For additional information about the Payment Card Industry Data Security Standard, visit SearchSecurity.com's PCI DSS resources page.
Where can we find information about PCI DSS compliance that is focused on those of us who are "Mom & Pop" shops?
Since most small organizations fall into the self-assessment category, a great resource is the Security Standards Council SAQ (Self-Assessment Questionnaire) section. Specifically these documents:
It seems the necessity of PCI compliance hasn't fully penetrated the Asian markets. Do you have any suggestions on how to achieve compliance for companies who do business in Asia, where adjusting to PCI standards aren't a priority?
Companies should be compliant regardless of where the payment information is stored, processed or transmitted. Even if processors in a particular locale aren't as focused on the standard, the companies (merchants/retailers) with operations in those locales should implement the same controls as they do in other areas of the globe.
If card data is entered via the virtual terminal of a third-party on a desktop PC where wireless is not enabled, do I need wireless scans?
All wireless networks within the CDE (cardholder data environment) need to be scanned pursuant to the PCI DSS wireless guidelines provided by the Council. If audit and test findings confirm there is no wireless on the virtual terminal and there is no wireless within the CDE, additional scans are not required (for example, note that the wireless scanning requirement is not addressed in SAQ C-VT specific to virtual terminal-only environments). Note, however, that if you use other devices beyond just the virtual terminal to store/process/transmit cardholder data (such as a PoS on your network), you will have to scan.
Is there a standard for isolating non-compliant custom systems that do not have a newer PCI-compliant version available? Let's assume this would be a software package without encryption in its database.
There are two standards for payment software – the PA DSS for commercial software and the PCI DSS for commercial software with significant customization and custom software. If the custom software is saving PANs in an unencrypted format, it is non-compliant with PCI DSS. The best options are to stop saving the PANs and use an alternative -- like masking, tokens or other unique identifier -- or find a way to encrypt the PAN data before it enters the database. If this is not possible, create a document explaining why, list compensating controls (such as increased monitoring and access control) and put in place a road map for mitigating or eliminating the problem. Although the compensating controls/road map will not mean a fully compliant RoC or SAQ, it does show good faith on the part of the company to work towards correcting the problem.
In terms of a policy strategy, should an enterprise's existing information security policies be amended to include PCI requirements, or do the requirements need to be addressed in PCI-specific policies?
In most cases the CDE (cardholder data environment) under PCI is a very small portion of the network and should be clearly zoned off from the rest of the corporate network activities. As a separate part of the network, a unique policy (or policy set) should apply for that zone. So PCI-specific policies should exist. However, parts of existing policy – for example strong password controls and reset – can be re-used in the PCI-specific policies where applicable.
Regarding encryption in requirement 3, if the decryption key is not present in the cardholder environment, is the system out of the scope of PCI?
In the FAQ section of the Council site it states: "Encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it." So if the entity does not have the key, that data may be deemed out of scope.
Does PCI require verification that there are no rogue wireless access points that may have connected to the POS network?
Yes. From the Council's Wireless Guidance: "These are requirements that all organizations should have in place to protect their networks from attacks via rogue or unknown wireless access points (APs) and clients. They apply to organizations regardless of their use of wireless technology and regardless of whether the wireless technology is a part of the CDE or not." And, "The purpose of PCI DSS requirement 11.1 is to ensure an unauthorized or rogue wireless device introduced into an organization's network does not allow unmanaged and unsecured WLAN access to the CDE. The intent is to prevent an attacker from using rogue wireless devices to negatively impact the security of cardholder data. In order to combat rogue WLANs, it is acceptable to use a wireless analyzer or a preventative control such as a Wireless Intrusion Detection/Prevention System (IDS/IPS) as defined by the PCI DSS."
Where is disaster recovery and business continuity planning covered in the PCI DSS requirements, or is it?
Disaster recovery and BCP are not explicitly called out in the 2.0 version of PCI DSS; however, incident response planning is. "12.5.3 - Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations." Also in the Penetration Testing supplement it states: "Perform testing in accordance with critical company processes including change control, business continuity, and disaster recovery." And, in the Application Reviews and Web Application Firewalls Clarified it states: "Adhere to all policies and procedures including change control, business continuity, and disaster recovery."
Would you define "scope" as the geographical area of the PCI servers? Or would you define "scope" as the SAQ requirements? It seems at times they are used interchangeably.
The scope of the audit surface is the cardholder data environment (CDE). The CDE is "The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components." So any system component in the CDE is in scope regardless of geographic location.
Shared accounts are prohibited according to PCI DSS as I understand it, but imagine if you have your network equipment management outsourced and the firewalls and switches for the cardholder environment are managed by a third party or a service supplier. In this scenario, you would need two-factor authentication for administrative access to the CHE, but what if the service provider/supplier has several technicians and you are using RSA tokens? Do you have to supply one authentication account and one RSA token per technician? Or is it necessary only to supply one account and one RSA token for the service provider/supplier?
You're right that shared accounts are prohibited by PCI DSS; Requirement 8 states: "Assign a unique ID to each person with computer access." Strictly speaking, to be compliant, a unique ID and two-factor token would need to be assigned for each person remotely administering the firewalls and switches.
- Can you speak to some of the feedback you have received from clients who have implemented a tokenization product, including some of the key areas to focus on when selecting a vendor?
We've received positive feedback from companies that use tokenization in the CDE to reduce scope. One that we spoke to and have mentioned publicly is Helzberg Diamond Shops, Inc.. However, we caution that to be completely effective, organizations need to also address scope reduction and zoning, document the tokenization implementation so it can be reviewed during audit, and confirm with your acquirer/processor that tokenization is acceptable. For vendor selection, the Council is working on tokenization guidance, but Visa Inc.has already issued its recommended guidance, Tokenization Best Practices.
- Speaking from a university standpoint, we take credit cards in many ways -- POS, Internet, MOTO – but we use only PA-DSS applications and we are hosted by a service provider, so we do not store any CHD. Our CHDE is really the PCs (and network) where the card data is entered or swiped. We have segmented all system components (PCs where CHD is entered or swiped) away from our regular network. It appears that many of the PA-DSS requirements are in reference to "stored" credit card data. Can you give me some advice on how to determine how much of the requirements apply to us given that we do not store CHD? We have secured all components that have CHD entered and we are running PA-DSS-compliant applications.
Sounds like you've done a lot of great scoping work. The PA-DSS applies to applications, but entities still need to be PCI DSS compliant. Since your applications are already PA-DSS compliant, focus instead on what matters to your university, which is attesting to PCI DSS compliance. If your transactions levels qualify you for self-assessment review, the self-assessment guidelines (please see question 1 for more information) and determine which one applies and complete that. In general, if you fall under multiple SAQs your acquirer/processer will want you to complete SAQ –D. However, to be sure, check with your acquirer/processor to confirm.
Can you offer advice on what to look for in an internal audit and reporting product for PCI DSS compliance?
There are multiple audit and reporting tool types that can be used in PCI DSS compliance. For example, a penetration testing system will return reports on vulnerabilities and exposures in the CDE, while a patching system will return reports on patch information, both of which apply. In many cases, when organizations think about a meta-console for reporting, it is a log or event/information aggregation console that brings together multiple reporting components for use in PCI DSS compliance work. For any tool, look for the ability to check for issues specific to PCI DSS (ex: password policy on servers and applications in the CDE) and report on these in a template that maps the finding to the specific requirement.
I have a question about PCI and the cloud. We are a PCI Level 1 merchant. We are thinking of moving our data center to cloud, Amazon to be specific. We understand that Amazon is PCI Level 1 compliant. Is it really possible to be a PCI-compliant Level 1 merchant in a cloud environment? Do you have any guidance regarding PCI in a cloud environment?
Amazon.com Inc. (Amazon Web Services – AWS) is, as of this writing, a PCI DSS Validated Service Provider. However, using AWS, or any Validated Service Provider, does not eliminate the need to entity using the service to be PCI DSS compliant . As Amazon notes, "All merchants must manage their own PCI certification. For the portion of the PCI cardholder environment deployed in AWS, your QSA can rely on our validated service provider status, but you will still be required to satisfy all other PCI compliance and testing requirements that don't deal with the technology infrastructure, including how you manage the cardholder environment that you host with AWS." So while a cloud provider can be third party validated as a PCI DSS provider, this doesn't mean they're certified to PCI or that entities using the service are automatically certified.
If you are going to host some or all of your CDE in the cloud, do so with a compliant provider. However, don't forget to annually check that the provider is remaining compliant with your CDE, as well as the parts of your CDE that are hosted in the cloud. Additionally, according to the PCI Security Standards, your RoC must "document the role of each service provider, clearly identifying which requirements apply to the assessed entity and which apply to the service provider." And:
"12.8 – If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers, to include the following:
12.8.1 – Maintain a list of service providers.
12.8.2 –Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data that the service providers possess.
12.8.3 - Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.
12.8.4 - Maintain a program to monitor service providers' PCI DSS compliance status at least annually"
In effort to ensure PCI compliance, we have a number of different products from different vendors, since there does not seem to be one full PCI compliance "solution." Is this by design? Is there any advantage to having each requirement met by a different vendor's product?
There are a number of components in PCI compliance and they encompass people, process and technology, and span both the physical and the logical. Also, all of the documentation related to policies and process. It would be extremely difficult (arguably impossible) for a single solution to do it all. The reality is that organizations use a number of different vendor solutions for the technical controls.
Some vendors provide products that meet different controls. For example, a vendor with a log aggregation or SIEM tool that also sells antivirus/malware or patch management. The big win is not necessarily to have all tools (or many tools) from the same vendor, but to be able to bring together reporting, logs, test and monitoring information in a centralized place to make oversight and compliance monitoring more comprehensive and efficient.
How can companies deal with call recordings in the call center when taking card payments by phone? Are there any mitigating factors?
Because there is not a lot of call center guidance in the PCI DSS, the Council addressed call center issues in a special FAQ #5362. "The Council's position remains that if you can digitally query sensitive authentication data (SAD) contained within audio recordings - if SAD is easily accessible - then it must not be stored."
Though this is not hosted on the PCI Security Standard Council Domain -- it is the official FAQ for the Council and can be accessed directly by clicking in the FAQs link at the top of the official Council page.
Also, please see question below for additional information on storage rules regarding sensitive authentication data (SAD).
Our call-recording solution requires manual intervention to bleep out the CV2 number. Is this sufficient as a compensating control to meet the standard?
If the CV2 (or any other sensitive authentication data/SAD) is not stored, this should meet the standard. Document how the manual process is implemented to ensure SAD is truly being deleted and not stored.
Alternately, according to PCI Security Standards Council FAQ "If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats."
If you have backups of credit card data in a secure location, is that a violation? How can it be mitigated?
It's not a violation -- it is part of a requirement! Requirement 9.5 explicitly states: "Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location's security at least annually." Remember to make sure the data was encrypted before it was backed up and that the personnel at the facility do not have the key to decrypt the data.
What are the rules for external scanning?
External scanning is covered in Requirement 11.2.2 – "Perform quarterly external vulnerability scans via an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).
Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by internal staff."
See the PCI Security Standard for a list of ASVs
PCI 2.0 lightly touches upon virtualization for the first time. Does this extend beyond virtual machine images to virtual appliances (e.g. use of virtual firewalls & virtual switches in hosted products)?
Yes, according to the Scope of Assessment for Compliance it does extend to virtual appliances. "System components" in v2.0 include, "any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors." Also note that virtualization is mentioned in Requirement 2.2.1: Implement only one primary function per server, "Note: Where virtualization technologies are in use, implement only one primary function per virtual system component."
Is a system that is not holding the cardholder data, but only processing it (like a Web farm) a part of PCI audit requirements?
Yes, if a system component stores, processes or transmits cardholder data or sensitive authentication data, it is part of the CDE and within scope of the PCI DSS audit. For additional guidance, refer to the Scope of Assessment for Compliance with PCI DSS requirements section of PCI DSS v2.0.
When do companies have to switch over to PCI 2.0?
For the absolute final word on compliance deadlines, check with your acquirer or specific card brand. In general, however, v2.0 went into effect on January 1, 2011 and there is a year to comply with the new standard. If you are in the middle of an assessment cycle that started in 2010 and the compliance assessment will be completed before the end of 2011, you can continue the process with v1.2.1. If you a starting a new assessment cycle in 2011, use v2.0.
If an organization has filled out the self assessment questionnaire (SAQ) and identified that it has not complied with the 12 DSS requirements, should the SAQ still be submitted? Or should the organization wait until the 12 requirements have been satisfied?
Before admitting defeat, see if there is any way your organization can get to be compliant. Don't forget, if a non-compliant system or process is not essential, it could be scoped out of the CDE and out of the compliance surface. Also don't forget about compensating controls. The ideal is to be fully compliant, but compensating controls provide a way for organizations to be mitigating risks as they work towards implementing better controls.
According to the Compensating Controls Appendix B in SAQ D v2.0: "Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls." Also, there is a compensating control worksheet that needs to be completed in Appendix C of the SAQ D v2.0.
If de-scoping the non-compliant system and compensating controls are not options, then you will need to check the "Non-Compliant" box on the SAQ and put in a target date for compliance. In most cases, your acquirer/processor will want to see this proof, and possibly ask your organization to fill out the "Action Plan" part of the SAQ; however, check with your acquirer/processor to be sure.
Let's talk about the mythical beast that is end-to-end encryption. Does it exist? More specifically, one of our audience members asked, "What if end-to-end encryption from the pin pad / card swipe POS is implemented? Does that take everything out of PCI scope?"
The Council is calling this P2PE for point-to-point encryption. Meaning turning the cardholder data into ciphertext (encrypting it) and then transmitting it, encrypted to a destination, for example, the payment processor. If the P2PE begins on swipe by cashier of the credit card at the PoS (point of sale) and continues all the way to the processor, it is not stored, and no one in the interim path has the keys to decrypt the data, then it could reduce the scope of the audit surface significantly. Caveats here are that everything will need to be implemented correctly, validated and tested. However, note that the entity still must be PCI DSS compliant – though compliance may be greatly simplified. And, at this time, the PCI Security Standards Council still deems P2PE an emerging technology and is formalizing official guidance, training QSAs on how to evaluate relevant P2PE components, as well as considering creating a validated list of P2PE solutions. For more information on the status of P2PE, please read the Initial Roadmap: Point-to-Point Encryption Technology and PCI DSS Compliance program guide.
Under what circumstances can an internal audit certify a merchant as being PCI compliant?
If the merchant qualifies for SAQ completion, internal audit can be responsible for the assessment and attestation process. "Each payment card brand has defined specific requirements for compliance validation and reporting, such as provisions for performing self-assessments and when to engage a QSA."
If the merchant must complete a RoC, it is possible to do the on-site assessment with an internal resource if the brand allows it. Check with your brand for specifics, Mastercard Inc., for example, has deemed that as of June 30, 2011, the "primary internal auditor staff engaged in validating PCI DSS compliance [must] attend PCI SSC ISA Training and pass the associated accreditation program annually."
What PCI and security implications do you anticipate arising with the new generation of contact-less cards, given that they are now being widely distributed?
If the data can be transmitted in a secure encrypted format over the RF from the contact-less card to a secure endpoint, the data should not be exposed. However, if the data from the card is in clear-text over the air, sniffing attacks will be a major concern. Also, key management and MiTMs may be problems depending on specific technical implementations.
Are quarterly penetration tests still required for wireless access points that are using WPA-2?
Yes, quarterly tests are required. Requirement 11.1 covers all known/unknown wireless access points regardless of protections on them. "11.1 - Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis." The reason for this is that one of the intents of this requirement is to ensure there are no rogue devices in the CDE.
Does Citrix sessioning between payment apps and hosted sites provide sufficient encryption for PCI compliance?
If the session is configured to transmit the data between the payment apps and the hosted site using an approved method (ex: SSL/TLS ) then it should be compliant for at least the transmission portion of the standard.
Requirement 4.1 -- "Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks."
- How much are organizations spending on PCI compliance? Can you provide a range both for one-time costs and annual maintenance?
There are two sides to this coin: cost of the audit and cost of compliance overall.
Audit cost: According to a recent Ponemon survey on PCI DSS trends (.pdf), the average cost of the audit itself is $225,000 for the largest (Tier 1) merchants, but the cost can range much higher or lower depending on complexity of the environment, size of the CDE, and other factors .
- Overall cost of compliance: In 2008, Gartner conducted a survey of 50 merchants and found that PCI costs had been increasing since 2006 (Gartner.com registration required) and cited costs averaging 2.7M for Tier 1 merchants, 1.1M for Tier 2, and 155k for Tier 3. Again, these are averages, so your particular case might be different.
- Requirement 2.2.1 mandates that critical servers provide a single-purpose service. If I have a single server hosting an e-commerce application with a Web server and database residing on a physical server, do I need to place the database on a separate server?
Yes, in most cases. Requirement 2.2.1 – "Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server." The intent of this requirement is to provide some protections if the underlying host, in this case the operation system running the database and e-commerce application is breached, causing one or both of the services to be exposed to attack. VMs are now allowed, so the same piece of hardware could be used with a hypervisor to separate the two services across two VMs. Alternately, if there is a critical business need, such as performance, for both primary functions to be on the same server, consider if this justifies a compensating control by completing the compensating control worksheet (Appendix C of the PCI DSS).
About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of SecurityCurve.
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.