Industry Observations-Technical Insight-Tools and Applications-Vulnerabilities-Web Application Security

“Crash Course – PCI DSS 3.1 is here. Are you ready?” Part II

Thanks to all who attended our recent webinar, “Crash Course – PCI DSS 3.1 is here. Are you ready?”. During the stream, there were a number of great questions asked by attendees that didn’t get answered due to the limited time. This blog post is a means to answer many of those questions.

Still have questions? Want to know more about PCI DSS 3.1? Want a copy of our PCI DSS Compliance for Dummies eBook? Visit here to learn more.

Is an onsite pen test a requirement in order to meet the PCI-DSS 3.1 requirement?

PCI-DSS 3.1 does require a pen test to meet requirement 11.3. However, it does not implicitly state that it needs to be onsite. Allowing access to internal web applications and systems via secure VPN or other means can be leveraged to allow outside access.

Requirements for devices such as iPads are not currently specified (although could be implied throughout requirements)…if using a third party secure app to process payments, what else must be done to harden the iPad, if anything?

When using 3rd party applications or services, you must maintain the same level of security with the partner in question. Sections 12.8.2 and 12.9 speak to keeping written documentation to ensure that there is agreement between both parties about what security measures are in place.

In regards to the 2nd part of the question, no additional measures need to be taken on the devices themselves. The application itself must adapt to be secure on whatever device it is running on, even if it is a bug/flaw in the device itself. It is a matter of what control you have to protect your card data. Unless you have a contract with the device vendor, a flaw on the device would fall out of that realm of control.

What about default system accounts (i.e. root) that cannot be removed – is changing the default password no longer enough?

The removal of test data mentioned in section 6.4 focuses on test data and accounts that are used during development. This is separate from section 2.1 that deals with vendor supplied system and default passwords. For things such as root that cannot be removed, changing the defaults is sufficient.

For a test account in production, we implement an agency with a Generic account, which becomes the base of the users underneath it. Is this considered a test account or do they mean ‘backdoor’ accounts for testing?

This is a pretty specific example, but it sounds like this “generic account” is core to your architecture. This does not seem like a test account. However, if it is possible to log into this “generic account,” then it is exposed to the same risk as any user would be.

Does the Cardholder name or the expire date need to be encrypted if you do not store the strip or the actual card number?

PCI DSS in general does not apply if the PAN is not stored, processed, or transmitted. If you are processing this data but not storing the PAN with the Cardholder Name and Expiration date, then you are not required to protect the latter two. PAN should always be protected.

For EMV compliance, is Chip + PIN the only PCI-compliant method, or is the commonly used Chip only compliant?

Either Chip+Signature or Chip+Pin is currently PCI compliant so long as the same PCI standards are followed as the full magnetic strip. PCI DSS has not taken a stance on Chip+Signature vs. Chip+PIN yet, likely because the latter has not been widely adopted. The US is a laggard in this regard, but is moving towards that direction.

If “Company X” accepts responsibility for PCI Compliance, and they use a WiFi that is secured by a password, are they fully compliant?

Using WiFi secured by a password for card transactions does not violate you for PCI inherently. However there are several sections of PCI that have strict requirements around implementing and maintaining a wireless network in conjunction with cardholder data.  They discuss this more thoroughly in PCI’s section on “wireless” (page 11).

Is social engineering a requirement of a pen test or is the control specific to a network-based attack?

Social engineering is not a requirement of the pen test or network based attacks. However, social engineering is mentioned in section 8.2.2 in regards to verifying identities before modifying user credentials. Social engineering tests would undoubtedly help in this area, but isn’t a hard requirement.

Does having a third party host your data and process your cards take away the risk?

We enter credit card information into a 3rd party website and do not keep this information.  Are we still under PCI?

If we use an API with a 3rd party to enter the credit card information, what is it that we need to consider for PCI?

Yes, in this situation you would still need to comply to PCI standards. When using 3rd party applications or services you must maintain the same level of security with the partner in question.  Sections 12.8.2 and 12.9 speak to keeping written agreements to ensure that there is agreement between both parties about what security measures are in place. Using an API with a 3rd party would be considered part of the “processing” of the cardholder data so any systems that leverage that API or transmit any cardholder data would need to conform to PCI standards even if no storage is occurring on your end.

How do you see PCI compliance changing, if at all, in the next few years as chip and PIN cards become ubiquitous in the U.S.?

PCI compliance will continue to change based on industry standards.  Chip+PIN cards are not yet widely adopted in the U.S., which may have had an impact in it not being a requirement in PCI DSS 3.1  As the U.S. and other geographic regions adopt Chip+PIN in larger numbers, we expect PCI to adopt it as a requirement to push even harder for full adoption.

Regarding change 6 (Requirements 6.5.1 – 6.5.10 applies to all internal and external applications), does PCI have hard standards regarding when zero day vulns or urgent/critical vulns need to be remediated?

PCI DSS does not have any specific requirements around patching zero day vulnerabilities.  However it does recommend 30 day patch installations for “critical or at-risk systems.”

Some vulns take longer than 60/90 days to be remediated. How does this impact a PCI review?

PCI DSS does not specify any particular remediation timelines. However, there must be a plan to remediate at a minimum. If you can show that you have a timeline to remediate  vulnerabilities that have been open for a longer period of time, you should still meet compliance.  If you give a plan to an assessor, and do not deliver on that plan, then there will likely be an issue.

Are V-LAN setups a legitimate way to segment PCI devices from the rest of the network?

When using 3rd party applications or services, you must maintain the same level of security with the partner in question.  Sections 12.8.2 and 12.9 speak to keeping written agreements to ensure that there is agreement between both parties about what security measures are in place.

Does the new PCI requirement state that we need to encrypt, not tokenize, storing PAN and CVV?

CVV storage is not permitted at all. Tokenization of PANs is considered to be the best practice, but is not a requirement. The requirement for PAN storage simply reads “PCI DSS requires PAN to be rendered unreadable anywhere it is stored.” This includes several methods of storage: hashing, encryption,  tokenization, etc.

For those of us using a third party processor for payments, has the requirement to have all elements of all payment pages delivered to the customers browser originate only and directly from a PCI DSS validated 3rd party have much impact on many companies?

Yes, the requirement to have an agreement with 3rd party services can have a disruptive impact on many companies.  What happens many times is that no agreement is put in place in regards to security testing ahead of time. Then either the company or their service providers are audited, which leads to a rush to get everything assessed in time. Identifying services and partners that deal with cardholder data ahead of time and putting agreements in place can alleviate a lot of problems.

Any specific requirements for Smartcards, CHIP and signature, CHIP and PIN, or use of mobile phones for payments?

Chip cards do not have any specific requirements in PCI as of today.  The data they contain must be treated the same as the magnetic strip data. Use of mobile phones for payments must be validated on a per app basis, and of course enforcing policies that do not allow these devices to be used on untrusted networks.

Do PCI rules apply to debit cards?

Yes, PCI applies to credit and debit card data.

How would you track all systems if you are scaling based on demand?

If these are identical systems scaling based on demand, then an inventory of each individual appliance would not be necessary as long as there is a documented process on how the system scales up, scales down, and maintains PCI security standards while doing so.

How do we remain PCI compliant if we use an open source solution as part of our application that has a known vulnerability and (at a given time) has not yet been remediated?

Remaining PCI compliant is an ongoing process.  If you take a snapshot of any organizations open vulnerabilities you are likely going to find issues.  Being able to show that you have processes in place for remediating vulnerabilities, including those introduced by 3rd party solutions is part of meeting compliance.

How can we secure/protect sensitive data in  memory  in  Java and Mainframe Cobol environments?

Sensitive data existing in volatile memory in clear text is unavoidable.  The application must understand what it is storing before it can store it.  However there are several attacks that can be avoided to expose these values in memory such as Buffer Overflow attacks.  Preventing these types of attacks will eliminate the exposure of sensitive data in memory.

Is OWASP top 10 vulnerabilities  the only modules to be discussed with developers to be compliant with PCI DSS requirements 6.5?

PCI DSS recommends that developers be able to identify and resolve the vulnerabilities in sections 6.5.1-6.5.10.  The OWASP top 10 covers many vulnerabilities from these sections, but not all of them. Additional training would be required to fully cover those sections.

Tags: Vulnerabilities