Skip to content ↓ | Skip to navigation ↓

The epic Target breach is still dominating headlines as details trickle out into the press, and it may well prove to be a pivotal event in data security for the payment card industry, which is making preparations for changes to the industry’s security standards.

Last year the Security Standards Council (PCI SSC) released a draft of version three of the PCI DSS,  which includes six new requirements that are to be considered best practices until they officially become compliance requirements in mid-2015.

In recent and very popular webcast we conducted (recording available here), the first of three in our compliance series on PCI DSS 3.0, we provided some insights on the notable requirements and clarifications that have been introduced with PCI DSS 3.0, and provided some practical suggestions of what you may want to start considering how to successfully navigate your audit preparations for v3.0.

Our subject matter expert for the session was Jeff Hall, a senior security consultant and qualified security assessor (QSA) with FishNet Security who has over 30 years of information technology and security experience, and is also the QSA behind the popular PCI Guru blog.

With several hundred attendees participating in the webinar, it was impossible to address all of the pertinent questions about the changes to PCI DSS with the release of v3.0, and Hall was gracious enough to set aside some extra time to provide some additional details on specific issues of interest.

In the first follow up article, Hall fielded queries on a range of subjects, including certified applications and application developers, web-only merchants and the new penetration testing requirements, Encryption issues, cloud-based services, and concerns over continuous compliance.

In this article, Jeff Hall answers several more specific questions regarding PCI DSS v3.0 as it relates to smart cards, tokenization, PoS monitoring, Wi-Fi issues and more.

Smart Cards and PCI DSS 3.0

One of the attendees inquired about the implementation of “smart cards” –  what most people refer to as “chip and PIN,” although the PIN portion is technically optional and is part of the transaction process as with a debit card.

Hall notes that smart cards come in several varieties, but for the most part are are based on the EMVCo model that has been in effect Europe for several years. these cards have a chip embedded in them that authenticates them as the real deal, thus thwarting cloning of fraudulent cards.

“The original smart card was the Europay, a MasterCard and Visa card that was originally developed by its namesakes to minimize card cloning in Europe in the early 1990s, and the EMV standards are now managed by a separate entity named EMVCo,” Hall said.

“There are also smart cards that operate through near field communication (NFC). These are broken into two types – RFID and EMV.  RFID type cards are essentially just like magnetic stripe cards with the RFID storing the track data in a chip as well as on the magnetic stripe,” Hall explained. “EMV cards have the EMV chip as well as an RFID.”

There are also a number of “eWallet applications” that run on smartphones with NFC capabilities, such as Google Wallet, ISIS and others.

“These applications securely store your credit card information digitally on the smartphone and then use NFC to provide it for payment,” Hall explains. “Some of these eWallet applications can do the same thing through 3G/4G cellular, Wi-Fi or Bluetooth, but I have yet to see a merchant that advertises they can accept a payment via those communication methods.”

The there is “Coin,” a smart card solution slated to be released in the Summer of 2014, which looks like a credit card, but is slightly thicker and has an LCD display and allows for swiping.

“Based on my understanding, the user pulls up the account they wish to use based on the display and then presses a button to have that account generated for swiping,” Hall said.

“The only problem I see with it is that you swipe the card into a smartphone for programming the Coin. My guess is that your smartphone may be inadvertently storing the track data when the swipe occurs,” which could result in data vulnerabilities. “I would assume that the device also encrypts the data but they do not say in their video.”

“All of the aforementioned solutions are all transmitting the data securely, and in the case of the smartphone applications, they are storing the cardholder data securely,” Hall said. “In the case of ISIS, the application gets its information from the card brand or bank, not by data entry, so my guess is that it has track data when the data is sourced directly.”

In general, chip and PIN solutions have been successful, but implementation would require hardware and system upgrades that could be quite costly, and in the end it may come down to a cost/benefit analysis. It is likely that this issue will remain in question for some time to come.

Video Surveillance of PoS Terminals

Another attendee inquired about compensating controls for merchants who do not have surveillance cameras on their point of sale (PoS) terminals constantly to prevent tampering.

Hall says that if you are not going to continuously monitor PoS terminals with video cameras, then you need to have the following in place to know if and when they have been compromised:

  • Locking terminal cradles: Keys to the cradles should be limited to the store manager and support personnel.
  • Monitoring on the terminal such that if it is unplugged from the network, an alert is generated and followed up on by help desk personnel. “The most obvious condition would be any terminal that is disconnected from the network when the store is closed,” Hall said. “However, any terminal that is disconnected from the network should have a help desk ticket indicating the issue that resulted in the terminal being unplugged. No ticket, it is probable that an unauthorized swap out occurred.”
  • Monitoring of network traffic from terminals to anywhere other than your transaction processor(s). “If there is any network traffic from any terminal going to any network destination other than your transaction processor(s), you need to take that terminal out of service so it can be examined.”
  • Confirmation of any maintenance or swap out of the terminal with the help desk. “No ticket, no maintenance or swap out,” Hall advised.

Wireless Application Protocols (WAP) and PCI DSS 3.0

Another attendee of the webinar asked Hall if he could comment on the rationale for including WAPs which logically could be considered to not be in scope if the merchant is using segmentation to divide a very small in-scope environment from the rest of the enterprise network, which would be out of scope for PCI DSS 3.0.

Hall says that any wireless technology is considered suspect because the airwaves are exposed to anyone with the right technology to monitor transmissions without the owner’s knowledge.

“As a result, the PCI SSC has come to view any wireless networking technology used as being a threat – whether cellular, Wi-Fi, Bluetooth, etc.,” Hall explained. “Since Wi-Fi is so pervasive, and has been used to compromise card data in a number of breaches, the focus of the PCI standards ends up being more on Wi-Fi and not the other wireless technologies.”

As such, any wireless access point is a potential point of ingress into your network, so having the wireless segregated from the cardholder data environment (CDE) is not enough because it likely has access to other parts of your network outside of the CDE.

“Once wireless is compromised, an effective attacker will compromise one or more connected systems that will allow them access to the CDE,” Hall said. “Once inside your network, the attacker will likely move their command and control activities to more traditional connections, but leave wireless as a backup to regain access if discovered.”

“I can tell you from experience that your wireless management and detection system will not necessarily detect attacks the way the vendor has explained in their documentation and training, or your staff might expect,” Hall continued.

“As a result you probably will not detect such an attack, if you detect it at all, until well after it has successfully compromised your network. This is why you need to run penetration tests against your wireless to understand what attacks would look like when detected. These are the key reasons as to why the Council keeps up the pressure on organizations to secure, monitor and control wireless.”

eCommerce Merchants and Third-Party Payment Services

An attendee asked if Hall could discuss the changes for eCommerce merchants who host a Web store but use a redirect to a third party to actually process the payments, such as Authorize.net.

Previously, some Web stores had been considered out of scope because they didn’t actually handle any card or payment data. Now, there is speculation they may be pulled back into scope because of the possibility of man-in-the-middle (MitM) attacks that could intervene in the redirect and intercept payment data.

Hall recommends such merchants consult the PCI SSC’s information supplement titled PCI DSS E-commerce Guidelines (PDF) published in January 2013, as well as the Open Source PCI Scoping Toolkit to understand why a Web store is in scope.

“The bottom line is that your Web store has the ability to influence the inbound connectivity of the systems that actually process the cardholder data – a category ‘2b’ system in the scoping toolkit’s nomenclature,” Hall explains.

“The reason your Web store is in-scope is that attackers could gain access to your Web store, modify the re-direct to their own payment page/widget, collect cardholder data as well as pass it through to your processor, and you would never be the wiser until customers began complaining to their banks about fraud and they traced it back to your Web store,” Hall said.

He recommends having some basic controls in place to ensure that the re-direct does not get modified without your knowledge.

“There are a variety of ways to accomplish this depending on the operating system and platform you are using to run your Web store,” Hall continued. “However, you do not need to implement the entire suite of PCI DSS controls to accomplish this fact, as stated in the scoping toolkit.”

Hall further explains that Web stores doing re-posts of cardholder data are much clearer as to why they are in-scope, as they actually process the cardholder data and then pass it on to the transaction processor.

“The cardholder data may only be in memory, but it is still processed on the Web store server for some length of time, and as we have seen with BlackPOS and vSkimmer, the attackers have recognized this fact and are going after cardholder data in systems’ memory,” Hall pointed out.

“In the case of re-posts, your systems are considered category ‘1a’ systems and are fully in-scope for PCI compliance, and would therefore need to meet all relevant requirements.”

PCI DSS 3.0 and Tokenization

The last question Hall addressed was in regard to whether tokenization will still be a strategy to significantly reduce PCI scope for an organization. Tokenization occurs at the back end of the transaction process when the processor tokenizes the PAN and passes it back to the merchant.

“As a result, there is still the process of getting the sensitive authentication data (SAD) from the customer’s card, through the terminal and to the processor which is all still in scope to one extent or another depending on transmission encryption and processing and storage considerations that might occur in those processes,” Hall said.

“As such, tokenization will have no change in scope impact regardless of the version referenced.”

 

The PCI DSS v3.0 Webinar Series Continues:

  • March 2014: Creating a Culture of Security: PCI’s Best Practices for Implementing Security into Business-As-Usual Activities.

 

Related Articles:

 

Resources:

picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].

 

picDefinitive Guide to Attack Surface Analytics

Also: Pre-register today for a complimentary hardcopy or e-copy of the forthcoming Definitive Guide™ to Attack Surface Analytics. You will also gain access to exclusive, unpublished content as it becomes available.

 

Title image courtesy of ShutterStock