Archive for the 'PCI PTS' Category


Answering Some Dream Team Questions

After our PCI Dream Team event on May 17, I thought I would take some questions that do not require long and involved answers and publish them in this post.  FYI – I have edited and spell checked these, so they likely do not look like you entered them but they should convey your questions as you asked them.  Hopefully I answered on of your questions.

Q: Does anything special need to be done with the use of Virtual Terminals?  We use the virtual terminals to manually enter credit cards from time to time.  The computers used are normal user computers with the basic security done, but I have been wondering if they need to have extra limitations or security put in?

A: There are a lot of solutions that imply they take the workstation/terminal out of scope or magically reduce scope when using virtual desktop (VDI) solutions.  None of it is true.  If a device is used to enter PAN (regardless of HOW), it is a Category 1 device because it is used to enter PAN.  The bottom line is that any device used to enter PAN is in-scope for full PCI compliance.  There is no “magic” to change that fact.

Q: Do all POI devices have a keypad? I’m thinking of PC’s with integrated MCR’s – will those all change to separate POI’s with a keypad?

A: All point of interaction (POI), aka card terminals, that are customer facing have a keypad because they need to be able to accept PIN entry.  Merchants that are going to P2PE/E2EE solutions end up with a separate POI that is connected to the POS PC/terminal via USB so that the POS solution can communicate the total price of the sale as well as to know if the transaction is approved or declined.  The POI securely communicates with the transaction processor over Ethernet or using the USB connection and the Ethernet connection of the POS PC.  In both cases, the POS PC never has access to the sensitive authentication data (SAD)/cardholder data (CHD) as it is encrypted at the POI.  However is using an E2EE solution, the QSA will need to validate that the E2EE solution to ensure that they do in fact encrypt at the POI and therefore the POS PC/terminal is out of scope.  In addition, the merchant will have to contact their acquiring bank to get formal approval that the E2EE solution gives scope reduction for the merchant.  This will likely require the QSA to provide their evidence and assessment procedures to the acquiring bank for that approval.

Q: Are administrator workstations always in scope for PCI DSS regardless if an administrator is connecting to CDE servers via jump box?

A: Yes, because they are “connected to” systems when they access the jump box.  They may not be entering cardholder data (CHD), but they likely can access it or influence its processing/transmission because they are administrators.  That said, I would treat them in the Open PCI Scoping Toolkit vernacular as a Category 2x system.  That means they can probably avoid the bulk of PCI requirements but, at a minimum, need to be properly security hardened, kept updated, have anti-virus/anti-malware and are monitored “periodically”.  And as a reminder, administrators will need to use multi-factor authentication (MFA) after January 31, 2018 when accessing the cardholder data environment (CDE).

Q: Are you having/forcing your clients to follow the December scoping guidance, and are you bringing administrator workstations into scope?

A: I guess I am curious as to when anyone would have thought that administrator workstations ever were out of scope?  Nothing has changed in that regard as they were always in scope for PCI compliance.

Q: Are “crash kits” in restaurants for use when the system is down in scope for compliance?

A: The kits themselves are not in scope, but when they get used, the forms that get generated which contain the embossed image or handwritten PAN and other sensitive authentication data (SAD)/cardholder data (CHD) place those forms in scope for PCI compliance.  They therefore need to be securely stored, securely transmitted and subsequently securely destroyed in accordance to the relevant requirements in section 9.

Q: Does pushing non-cardholder data out of CDE system excludes connected system out of PCI scope? For example pushing non-cardholder data such as CPU usage for monitoring or number of transactions per day used for reporting etc.

A: According to a discussion at the 2016 Community Meeting and a subsequent Assessor call, the Council has publicly stated that if it can be unequivocally proven that the flow is only outbound from the cardholder data environment (CDE) to a device and that the data does not contain cardholder data (CHD), that device can be ruled out of scope.  However you have to get your QSA to buy into that argument and I do not know too many QSAs that will agree with that decision.  In my experience, there is still too much of a risk that cardholder data (CHD) could leak through that flow and saying it is out of scope is not accurate nor is it good practice as it leads to an exfiltration point that is not monitored.  The question you have to ask yourself is, how will it look in that newspaper headline when your organization is breached that you ruled it out of scope because it was outbound only?

Q: PCI DSS requires a firewall in place, are host level firewalls meeting that requirement?

A: Yes, as long as they perform stateful packet inspection (SPI), they are properly and securely configured and they are appropriately monitored like any other in scope firewall.

Q: Regarding vulnerability assessments for internal scans, do we have to address medium vulnerabilities or only critical and high vulnerabilities?

A: The PCI DSS and the Council have been very clear on this which is why it is disconcerting when this question constantly gets asked.  The guidance for requirement 6.2 is very clear as it states, “Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months.”  The bottom line is that you need to apply ALL patches/updates to all in scope systems as soon as possible.  So get on with patching and updates, no excuses.

Q: More than once I’ve been told that the decision to implement PCI compliant controls is a financial decision. What are the expected fines and penalties for failing?

A: No organization gets to ignore any PCI requirement because of financial or any other reasons.  However in those cases where a requirement cannot be directly met, an organization must then come up with compensating controls that go above and beyond that requirement in order to be in compliance.  In my experience, it is almost always cheaper to meet the PCI requirement than to go the compensating control worksheet approach.  You will have to talk to the card brands as they are the ones that come up with the fines and penalties.

Q: Do you ever foresee the card brands implementing any sort safe harbor clauses in regard to PCI?  If a merchant is doing their best to be secure and (more importantly, as far as PCI is concerned) compliant and they are breached, as it stands right now, PCI will not help you.  Instead, PCI seems to be wielded as a weapon to extract fines from the merchant.

A: You are joking right?  LOL!  Actually, with merchants going to P2PE/E2EE and tokenization solutions, I could envision changes in the PCI compliance process at the merchant level because the risk is only with the POI.  Time will tell.

Q: Have you heard anything further regarding the FTC’s review of PCI?

A: Not a word and I would not expect to hear anything until the FTC decides to tell us anything.  I do know that issues regarding the FTC’s information requests from the QSACs were supposedly worked out and that the requested information was delivered to the FTC.  But that is the extent of my knowledge on the matter.


2016 North American PCI Community Meeting

It was a hectic week out in Las Vegas at the Community Meeting this year.  I wish I had more time this year to just hang out with everyone, but I was in the middle of a number of assessments that needed to get done, so I was working at night and attending sessions during the day.

By the time you read this, the slide decks from the sessions will have been posted on the Council’s Web site.  So all of you that attended will be able to download those presentations.  You go to the link provided in the program guide, provide your name, organization name, email address and the password from the program guide (ve4eqepR) and you are in.

The Council tried the 20 minute “TED Talk” format again with the Wednesday sessions.  A number of the sessions I attended could have easily used an extra 10 minutes if not a complete hour.  I know the Council is trying to move things along and get a lot of information covered, but trying to discuss topics like “the cloud” or EMV standards just cannot be properly accomplished in 20 minutes.  I do not care how good a speaker or organized the presentation.

Here are some of the more notable highlights.

The Assessor Session Is Back

Possibly the most anticipated session of the Community Meeting this year was the return of the Assessor Session after being missing for two years.  But unlike previous years where this session occurred before the start of the Community Meeting, the return of the Assessor Session was moved to the end of the Community Meeting.  I heard a number of complaints throughout the week from assessors about being at the end of the meeting.  Yet when Thursday lunch came around, there were a lot of QSAs, ISAs and ASVs that adjusted their travel schedules (Guru included) to attend this session.

While I originally agreed with people that moving the Assessor Session to the end was not a good idea, the more I have thought about it, the more I think it was better at the end.  That way assessors can have questions covering topics that come up during the meeting get answered while we are all together.  I know we all want to get home, but I think the Assessor Session offers more value to all of us being at the end.

On the not so good side, the Council chose to use up an hour and 10 minutes to present a variety of topics, some of which took way too long to discuss.  But the larger question was why was this material not presented during the main conference?  Not only did all of the meeting attendees miss out, but there were people that did not get their questions asked.  I am also sure that running long discouraged a lot of people from asking questions as well.

That said, there were a number of good questions asked during this session and the Council rewarded five people with large PCI SSC coffee mugs for their “good” questions.

One question though really created a stir.  I will address that question regarding multi-factor authentication (MFA) as a separate post to be published later.  However I will say this about this discussion.  The Council really needs to go back and re-think their position on MFA if what they said is accurate.

The Council was asked about SAQ A and where it is headed.  The concern in the assessor community is that the mechanism that issues/controls the iFrame/redirect needs protection.  However the changes to SAQ A for v3.2 did not seem to address this obvious risk.  Based on how the question was answered, I am guessing that the hosting community is trying to keep SAQ A as simple and easy as possible regardless of the risk.

Another area that the Council agreed to review was the change to requirement 3.2 in the ROC Reporting Template.  In v3.2 of the template you can no longer mark those requirements as Not Applicable however it was pointed out that an ‘NA’ was still allowed in the SAQ D.  The reason for seeking this clarification was related to past comments from the Council to follow SAQs for P2PE (SAQ P2PE) and outsourced eCommerce (SAQ A) when filling out a ROC for merchants with these solutions.  It was pointed out that neither of these SAQs has requirement 3.2 in them, so how is a QSA/ISA supposed to respond to it in the reporting template if it cannot be marked as ‘NA’.

Understanding The Current Data Breach Landscape (aka Verizon DBIR Report Discussion)

When Verizon sends out Chris Novak, you know you will get a great presentation on the data breach incident report aka ‘The DBIR’.  This year was no exception albeit somewhat depressing as Chris again pointed out that most breaches are the result of sloppy operations, lax security and insecure applications.  Essentially security issues that we should have gotten past a long, long time ago but have not.

Architecting for Success

Who better to talk about success than a representative from the Jet Propulsion Laboratory (JPL) talking about how to develop spacecraft to explore the most inhospitable environment we know, outer space and planetary bodies.  Brian Muirhead was the keynote speaker on Wednesday and is the Chief Engineer for the Mars Science Laboratory, the group that designed and developed the various Mars exploration rovers.  He gave a great discussion on how to look out for problems and develop self-managing devices.  Very interesting and I am sure an eye opener for people that we need to stop accepting the sloppy and messy solutions we get for handling cardholder data.

Internet of Things Keynote

The Thursday keynote was just a great time.  While there seemed to be very little directly relevant to PCI compliance presented by Ken Munro and an associate from Pen Test Partners, it was a fabulous time exploring the wonderful world of flawed technology from a tea kettle, to a refrigerator to a child’s doll.  In the case of the child’s doll, they removed the word filter database and therefore allowed the doll to say things that no child’s toy should say.

What was relevant to PCI was the ease with which these folks were able to reverse engineer firmware and software used by these devices.  It gave a lot of people unfamiliar with IoT and penetration testing in the room pause as to how seemingly sophisticated technology can be easily abused.

Cloud Security

While it was great to see Tom Arnold from PSC, the even better thing about this presentation was the fact that Amazon provided an actual human being, in the form of Brad Dispensa, to talk about Amazon’s EC2 Cloud.  While billed as a discussion on incident response, the session provided great insight into AWS’s EC2 service offering as well as the variety of new tools available to manage the EC2 environment and also provide auditors and assessors with information regarding the configuration of that environment.  The key take away from this session is that organizations using EC2 can provide everything needed for conducting a PCI assessment using their EC2 Master Console.


Brian Byrne from EMVCo gave a great 20 minute session on EMV.  The slide deck will be more valuable than the presentation because he had so much content to share and so little time to share it in.  Of note was his discussion of version 2.0 of three domain secure otherwise known as 3D Secure or 3DS.  While v1.0 will remain under the control of Visa, EMVCo has taken over management and development of the 3DS standard.  The new version is in draft and only available to EMVCo members, so this was the first time I had been able to see what the new version has to offer.  But because of the time constraint, I will need to wait for the slide deck to be published to know more.

PCI Quality Assurance Program

Brandy Cumberland of the Council provided a great presentation on the Council’s quality assurance program that all QSAs have become familiar.  I appreciated her discussion of James Barrow who took over the AQM program after most of us wanted to kill his predecessor for creating one of the most brutal QA programs we had ever seen.  James efforts to make the AQM program more relevant cannot be underestimated as he took over a very troubled affair.  This was a bittersweet discussion as James passed away right after last year’s Community Meeting and will be greatly missed by those of us that came to know and respect him.  Brandy took over the AQM program when James left the Council and has been doing a great job ever since.  She is possible one of the best resources the Council has and does the AQM program proud.

Application Security at Scale

The last great session of the conference I saw was from Jeff Williams of Contrast Security.  The reason this session was great was it discussed what application developers can do to instrument their applications for not only security, but also for operational issues.  He introduced us to interactive AppSec testing (IAST) and run-time application self-promotion (RASP).  The beauty of this approach is that applications get security in the form of embedded instrumentation that results in actionable analytics which then allow decisions to be made to respond to threats to these applications.  It sounds like an interesting approach and concept and I cannot wait to see it in action.

As always, it was great to see and catch up with all of my friends in Las Vegas at the PCI Community Meeting.  It was also great to meet a lot of new people as well.  I look forward to seeing all of you again next year in Orlando.


Is The PCI DSS Even Relevant Any More?

First the National Retail Federation (NRF), then bloggers.  Organizations and people are piling on the PCI SSC and standards all because of the United States Federal Trade Commission’s (FTC) fact finding project.  Seems like PCI is now a bad three letter word.  But with the changes that have been implemented or will soon be implemented, I am starting to wonder about the relevance of the PCI DSS.  So I thought I would explore these topics and explain what has lead me to that conclusion.

Ever since the FTC announced there little fact finding mission, I have consistently said that the FTC is late to the party.

Why do I think the FTC is late?

The FTC’s fact finding efforts are I am sure in response to the Target, Michael’s, Home Depot, etc. data breaches which resulted in tens of millions of payment card accounts being exposed and potentially used for fraudulent purposes.  Remember, they are a governmental body, so taking action can take a bit of time, in this case at least three years and longer than most people would have desired.  But they eventually got around to it.  While this fact finding effort is a valid way to get up to speed on a problem, the trouble is that the threat landscape has changed since those notorious breaches and the FTC got its act together.

What in the threat landscape has changed?

The vast majority of mid-sized and large retailers have or are in the process of implementing point-to-point encryption (P2PE) or end-to-end encryption (E2EE) and tokenization solutions to minimize their PCI scope to only the point of interaction (POI) otherwise known as the card terminal.  As a result, the threat of large scale breaches at these merchants is or soon will be in the next 12 to 18 months (based on my knowledge of a large number of such efforts) near zero.  The reason being is that these merchants’ point of sale (POS) and other systems will no longer have access to cardholder data (CHD) or sensitive authentication data (SAD).

How can the threat be near zero?

The threat with P2PE/E2EE and tokenization limits scope to only the POI and is very, very low because of how the POI must be implemented to work with P2PE/E2EE and/or tokenization.  I am not going to discuss in detail the security features of these solutions so as not to tip the hand of those organizations implementing them.  Let me just say that there is a lot of information required that must be loaded into the POI in order to swap out terminals.  Even then, there are additional controls involving the registration of the device by the merchant and/or service provider that preclude terminal swaps without generating some form of alerts.

The one threat that still does remain is the use of an overlay for skimming cards.  But that risk varies from POI vendor to POI vendor and even by POI model within a vendor.  And it is not like vendors have not taken notice of the overlay problem.  Vendors have gotten a clue and are changing the design of their POI to make them as difficult as possible to use an overlay.  I have a client that went with a POI that has various angles, long swipe tracks, LED lights and other features that would make an overlay very expensive to engineer but also very difficult to appear seamless to customers and clerks.  Over time I expect to see all POI manufacturers adopt strategies to minimize the ability to use overlays.

The result of all of this is that merchants are no longer the risk (if they even present a risk) they were two or more years ago.

So who or what does that leave at risk?

ECommerce Web sites are still a huge problem.  EMV as it exists today does nothing to stem the problem of online fraud.  Even if a merchant has outsourced eCommerce, they still have to manage that environment as well as deal with the chargebacks and disputes that come from eCommerce card transactions.  I have heard rumors of solutions that are coming to address eCommerce, but I have yet to see any formal announcements of those solutions.  So for the foreseeable future, eCommerce will still be in-scope for some amount of PCI assessment.  So merchants with an eCommerce presence will likely still have to address some form of PCI assessment for that environment.

Any merchant that has not gotten on the P2PE/E2EE and tokenization bandwagon.  All merchants should be getting POI that encrypt and/or tokenize at the swipe or dip of a customer’s card.  Adopting such solutions will leave the merchant with only having to comply with requirements in 9.9 and 12.  I know for some merchants that will mean an investment, but the payoff is extremely reduced PCI scope and effectively taking almost all of the risk out of card payments.

The organizations that end up with a huge target on their backs are any service providers, transaction processors, issuers or financial institutions that have CHD and/or SAD stored in their files and/or databases.  An unfortunate fact of life is that transaction processors, issuers and financial institutions are always going to have to have some amount of CHD/SAD in their files and databases because of the nature of their business.  It is these organizations where the full on (i.e., Report On Compliance or ROC) PCI DSS assessment will never go away.

For merchants that have moved to P2PE/E2EE/tokens, I could see a move to an annual self-verification that those solutions are still implemented and functioning as designed.  I could additionally see that, every three years or so, the card brands requiring an independent assessment by a QSA/ISA that the controls for P2PE/E2EE/token solutions are still in place and functioning correctly.  The reason for independent verification is that changes get made and those changes might affect the environment making it less secure.  For merchants not using P2PE/E2EE/tokens, I would think the current SAQs and ROC will remain in place with an annual assessment required.

Will other PCI standards be marginalized or disappear?

The PA-DSS will never leave us.  Software developers need to develop secure code and those service providers, transaction processors, issuers and financial institutions that store CHD/SAD need applications that do that securely, so there is a built in constituency for the PA-DSS.  ECommerce solutions are also still going to need PA-DSS validation.  But regardless of whether P2PE/E2EE and tokenization are implemented, any application potentially dealing with CHD/SAD will need to be assessed under PA-DSS to ensure that any CHD stored is stored securely and is erased securely.  Then there are the unknowns of the future.  You never know what might come along in the future, so there is always a possibility that some solution might need to securely store CHD or other payment related information.  The bottom line is that I find it very hard to believe that the PA-DSS could ever be dropped.

The PTS standard will also not disappear because those POI need to be validated to handle CHD/SAD securely and work properly regardless of P2PE/E2EE solutions.  The PTS is the only standard that is a card brand requirement, not a PCI DSS requirement.  It is the card brands that demand merchants use only PTS validated POI and I do not see that requirement going away when the POI is going to become the remaining target at merchants.

The ASV standard will not go anywhere as there will still be eCommerce solutions that will require vulnerability scanning.  Most merchants will implement eCommerce solutions that minimize their PCI scope using a redirect or iFrame.  Although I can see it coming that even using those solutions will still require the merchant’s eCommerce site, now deemed as out of scope, to be scanned for vulnerabilities.  The reason is that the invocation point of the redirect or iFrame is at risk of modification by an attacker.

One standard I do believe that will eventually go away is P2PE.  The reason is that there is very little to gain with a P2PE versus an E2EE solution.  Both solutions are essentially the same, the only additional work required for E2EE is documenting that E2EE has been implemented appropriately and submitting that documentation to the client’s acquiring bank and getting the bank to agree to the PCI scope reduction.  As a result, I believe that the P2PE standard will slowly and quietly disappear into the night as the cost of going through the assessment process along with the Council filling fees just cannot be justified by a lot of influential vendors such as Verifone and First Data.

There is my rationale for where I think things are hopefully headed.  Only time will tell if the rest of the world sees things the same way.


Living In PCI Denial

This was one of those weeks where you see something and all you can do is shake your head and wonder what some organizations think when it comes to PCI.  What added insult to injury in this case was that the organization arguing over PCI compliance is the manufacturer of card terminals, also known as point of interaction (POI).  It shocked me that such an organization was so clueless about PCI as a whole when you would think it is their business to know. But to add insult to injury, my client’s transaction processor and acquiring bank are also apparently clueless.

As background, I am working on a client’s Report On Compliance (ROC).  This client has almost completed with their roll out of an end-to-end encryption (E2EE) solution at all of their 4,000+ retail locations.  This E2EE solution will take all but the POI at those retail locations out of scope for PCI compliance.  That is the good news.

But if there is good news, you know there must be bad news.  In reviewing their documentation of this E2EE solution, I discovered that the POI vendor is providing management and updates to the POI through a terminal management system (TMS).  Since this TMS solution/service connects directly to my client’s cardholder data environment (CDE), I naturally asked the client for a copy of the vendor’s Attestation Of Compliance (AOC) for the TMS solution/service.

I thought those worthless PCI Certificates of Compliance took the cake.  Then, BAM!  I got the following message forwarded to me by my client from the POI vendor.  I have redacted all of the potential information that could identify the relevant parties and the TMS solution/service.

“Please see the follow up note below that you can send to your QSA for review and feedback:

  1. TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk. Since [vendor solution] does not have any card holder data at all, it falls outside of PCI requirements.  [Vendor solution] is merchant configuration and estate management tool only and as such, no payment card information passes through it, or directed to it.  In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.
  2. [Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website. Transactions are encrypted in hardware using the [encryption solution] keys which again [vendor solution] has no knowledge.  Transaction information can only be decrypted by [processor] the processor.  [Vendor solution] has no knowledge of this encrypted information being sent directly from the [vendor] to the processor.
  3. The beauty and simplicity of [vendor solution] semi-integrated terminal application is that is has all transaction data go directly to the Processor ([processor]) and no customer data is directed to the POS or [vendor solution] which makes the POS out of PCI Scope by the very nature of no card holder data in their environment.
  4. [Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application. Any questions regarding the certification should be directed to [acquiring bank] or a [processor] representative.

Let us know if your QSA has any further questions and we can also schedule a concall with all parties to address any concerns on [vendor solution] TMS and PCI.”

The first thing that wound me up is that this vendor is a business partner of my client’s transaction processor.  The processor is also a business partner of my client’s acquiring bank.  Those two organizations put forth this vendor to my client as being able to provide POI compatible to the processor’s E2EE and tokenization solution.  Obviously from this vendor’s response, these two well-known institutions did nothing in the way of due diligence to ensure that this vendor and its services were PCI compliant.

The second thing that totally irritated me is that there is no excuse for this vendor’s uneducated response.  Granted, this vendor is new to the US market, but they have been supplying POI to other merchants all over other parts of the world.  Which then starts to make you wonder just how lame are the banks, processors, card brands and other QSAs that they have not been called on the carpet about this before.  But that is a topic for another post and a good reason why the FTC is investigating the PCI compliance industry.

So let me take apart this vendor’s response.

“TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk.”

Wrong!  On page 10 of the PCI DSS the first paragraph under ‘Scope of PCI DSS Requirements’ clearly defines what is in scope for PCI compliance.

“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.”

The operative phrase the TMS solution/service falls under is “connected to”.  The TMS solution/service directly connects to my client’s CDE.  That solution/service may not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD), but it is directly connected to my client’s CDE.  As a result, according to the above definition, the TMS solution/service is definitely in scope for PCI compliance.

“[Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website.”

PTS certification is a card brand requirement, not a PCI DSS requirement.  Nowhere in the PCI DSS does it require that a PTS certified POI be used so I really do not care about this statement as it has nothing to do with my PCI DSS assessment activities.  If PTS were a PCI DSS requirement, then all of those people using Square and the like would be non-compliant.

“In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.”

“Transaction information can only be decrypted by [processor] the processor.”

True, your TMS solution/service does not have the encryption keys.  But the firmware delivered by the TMS solution/service does have access.  (Unless you are the first POI vendor I have ever encountered that spent the huge amount of money required to truly create a hardware-only encryption solution.)  Given the low retail price and discounting of your POI you gave my client, I very seriously doubt that is the case.  So the firmware that your TMS solution/service delivers is what is doing the encryption and therefore has access to the encryption keys.  So while the TMS solution/service does not have the keys, it could be used to deliver rogue firmware that could obtain them.

Then there is the firmware delivery itself by your TMS solution.  If someone hacks your TMS environment, how easy would it be for them to have it deliver a rogue version of your firmware?  Since my client has no AOC, I have no idea if your security measures surrounding your TMS solution are adequate to prevent such an attack.

“[Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application.”

Such a statement ranks up there with those previously mentioned worthless PCI Certificates of Compliance.  Any QSA is required to obtain an AOC for the TMS solution/service to ensure that it is PCI compliant or the solution/service must be assessed as part of the merchant’s PCI assessment.

PCI DSS requirements under 12.8 are very clear as to everything a merchant needs to be able to provide to their QSA regarding third party PCI compliance.  Primarily of which is that AOC for your TMS solution/service among other items of evidence.

So I have a conference call with my client’s bank to discuss this situation.  I pushed back very hard when they told me that my client needs to do a compensating control for their business partner’s incompetence.  I even got an “atta boy” from the bank for identifying to them that they have a PCI compliance and potential security issue.  But I could not make the bank budge on the compensating control so I am off to get that written.

The lesson to be learned from this post is that nothing can be taken for granted when doing a PCI assessment even when you transaction processor and bank are involved.  A lot of people and QSAs would assume that a POI vendor would know better and that their bank and transaction processor had vetted the POI vendor.  Therefore, why do I have to worry about this vendor?  However as I have pointed out, you can never take anything for granted even when it involves organizations that you would think would know better.

This is just one way of many that could result in an organization being breached.  The TMS solution/service is a gateway directly to the merchant’s CDE.  Yet there has been no PCI assessment of that solution/service to ensure that it is PCI compliant and the risk it could be subverted has been minimized.

Thank goodness it is the weekend.  Oh, wait.  This weekend’s project is my income taxes.  Looks like I will be cranky all weekend as well.


Crystal Ball Time

I was recently reminded that we are in year three of the current PCI DSS version. According to the PCI SSC’s standard lifecycle, that means the Council is starting to work on version 4 of the PCI DSS and PA-DSS.

So what is coming in version 4 of the PCI DSS? The Guru and his fellow PCI Wizards have some thoughts.

Business As Usual

I have written about this before. Everyone is betting that business as usual (BAU) will make its official appearance in the next version of the PCI DSS. If the past is any indication, BAU will most likely be a “best practice” until June 30, 2018 and then required thereafter.

For those that have forgotten, BAU was introduced as a concept with v3 of the PCI DSS. Pages 13 and 14 of the PCI DSS discuss the concept of BAU. The idea being to get organizations to integrate certain requirements of the PCI DSS into their organizational procedures to better ensure the security of cardholder data (CHD).

When BAU was first discussed back in 2013, I was able to identify at least 213 requirements that could be considered as BAU requirements (277 if you include Appendix A). Samples of BAU requirements include:

  • 1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to the cardholder data environment, including any wireless networks,
  • 2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards,
  • 1.a Examine the data-retention and disposal policies, procedures and processes,
  • 1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists,
  • 6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed,
  • 2.1.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12-month period, and
  • 8.1 Verify that a list of service providers is maintained.

Essentially, all the prospective BAU requirements are those that have some sort of timing involved for evaluating them.

Not only will adding in BAU be at issue, but I am guessing that the Council will probably reduce their use of the words “periodic” and “periodically” in the next version of the DSS. That is because with BAU they will likely begin to recommend actual minimum time frames for conducting these procedures. Known timings in v3 include annually, quarterly, daily, whenever changes occur and my personal favorite, whenever “significant” changes occur. Which means it will be all the more important for organizations to define what a “significant” change means in their environment.

But the introduction of BAU will likely not totally wipe out the use of “periodic” in the DSS. As a result, organizations will still have to define for those requirements that use “periodic” or “periodically” what the period is based on their risk assessment.

The bottom line is that if you have not been thinking ahead you need to get thinking ahead as to how BAU is going to impact your organization.

Requirement 9.9

New with v3 was the addition of requirement 9.9 which focuses on managing the risks to the card terminal or point of interaction (POI). Originally dismissed by most organizations as an annoyance, recent events with Safeway, other merchants and ATMs, security of the POI has come into laser-like focus. And with more and more merchants implementing point-to-point encryption (P2PE) or end-to-end encryption (E2EE), the security of the POI becomes all the more important as it is the only device that remains in-scope for the merchant. It is believed that with all of the issues with POI that have occurred, the Council will focus on beefing up 9.9 to address these higher risks by defining review schedules.

The first requirement that merchants need to deal with much better than they have is 9.9.1 which addresses maintaining an accurate inventory of POI. If a merchant has not implemented P2PE/E2EE, then the risk that a POI is swapped out for one that has been tampered with is extremely high. Tampering of POI is typically done such that the POI does not appear to have been tampered with such as installing a USB drive to collect data or installing revised software in the POI.

The quickest and easiest way to identify swapped out POI is to periodically review your POI inventory and make sure that all the serial numbers of those POI in use are the same as the numbers on your inventory. If they are not, then you should take that POI out of service and get a trustworthy one from your transaction processor.

Another control that you should use is tamper proof tape over the seams of the POI. If someone opens the POI, the tape will be torn and it should be obvious that the POI has been tampered with.

Earlier I distinguished merchant that have implemented P2PE/E2EE from those that have not implemented it. So what, if anything, should merchants with P2PE/E2EE implemented be doing? P2PE/E2EE solutions require the injection of an initial key into the terminal as well as recording a device number. If any of that information changes, the POI will not work. So if the terminal is swapped out, it will not work without the processor properly configuring the POI. This does not mean that the merchant does not have to manage their POI inventory, it just means that reviewing that inventory does not need to occur as often.

So how often should POI be reviewed against inventory? For merchants that have not implemented P2PE/E2EE, I would recommend no less than weekly. However, I do have clients that review their POI at every manager shift change. These are clients that have had POI swapped out and/or tampered with. Merchants that have implemented P2PE/E2EE should review their POI inventory at least semi-annually if not quarterly.

The next area that will likely be enhanced is requirement 9.9.2 which addresses the inspection of devices. I would anticipate that merchants will now be required to develop detailed procedures for the examination of POI by their retail management and cashiers.

But unlike with 9.9.1, this will not be broken down by those merchants that have and have not implemented P2PE/E2EE. Why? Because of terminal overlays that can be placed on top of certain POI and go unnoticed. These overlays can collect CHD regardless of whether P2PE/E2EE is implemented. As a result, examination of POI will likely be required to be done daily if not more often based on the assessed risk.

For merchants that have implemented E2EE, they may need to have to do an additional check depending on where E2EE is implemented. If the E2EE solution does not encrypt at the POI, then these merchants will also have to examine their point of sale (POS) in addition to their POI in order to comply with 9.9.2. One of the big reasons for this is because of Target style breaches where a memory scraper was used to obtain CHD because encryption was done at the POS, not the POI, and the connection between POI and POS was in clear text.

For merchants that use integrated keyboard card readers or USB card readers, there are other schemes such as keyboard loggers, USB adapters and other attacks that focus on the POS for obtaining CHD. For those merchants, they will also need to be doing daily inspections of their POS systems to ensure that equipment that does not belong is quickly identified.

The final requirement that will likely see changes is with 9.9.3 which is all about training retail personnel in the procedures of protecting the POI. With all of the changes to 9.9.1 and 9.9.2, you had to know that training would also have to change.

The biggest change will be the mandatory training. Yes, it was mandatory before, but with the focus on tampering with POI, training of retail staff will be very important. Why? Because they are the people on the front line and would be the ones most likely to notice something not right with their work area.

In order for these people to notice things out of order, they need to be trained, trained often and trained repeatedly. This is why security awareness training is so frustrating for security professionals is that it takes more than just one session every year to be effective. That and the fact that not everyone catches on at the same time with the same amount of training and there will be some people that never catch on.

The bottom line here is that your retail personnel will need to be drilled regularly on POI and POS security. How you choose to accomplish that training effort is up to your organization. But doing little or no training will not be an option.


The obvious change here will be the integration of the new deadlines for SSL and early TLS.

That said, the Council may actually provide some additional changes in section 4 regarding secure communication over TLS. In addition, by the time v4 of the PCI DSS is released, TLS v1.3 will likely be an official standard so changes in that regard may also be included.


Finally, I am sure there will be the usual wording and clarification changes that have come with every prior release.

Depending on any breaches that occur in the next few months, there may be some additional surprises in v4 to address the vulnerabilities identified by those breaches.

So there you have it. Start getting ready for the new PCI DSS v4 that will show up around November 2016.


Keeping It Simple – Part 1

Apparently, I struck a nerve with small business people trying to comply with PCI.  In an ideal world, most merchants would be filling out SAQ A, but we do not live in an ideal world.  As a result, I have collected some ideas on how merchants can make their lives easier.

Do Not Store Cardholder Data

It sounds simple, but it amazes me how many small businesses are storing cardholder data (CHD).  In most cases, it is not like they wanted to store CHD, but the people in charge just did not ask vendors that one key question, “Does your solution store cardholder data?”  If a vendor answers “Yes”, then you should continue your search for a solution that does not store CHD.

Even when the question is asked of vendors, you may not get a clear answer.  That is not necessarily because the vendor is trying to hide something, but more likely because the salespeople have never been asked this question before.  As a result, do not be surprised if the initial answer is, “I’ll have to get back to you on that.”  If you never get an answer or the answer is not clear, then you should move on to a different vendor that does provide answers to such questions.

If your organization cannot find a solution that does not store CHD, then at least you are going into a solution with your eyes open.  However, in today’s payment processing application environment, most vendors are doing all that they can to avoid storing CHD.  If the vendors you are looking at for solutions are still storing CHD, then you may need to get creative to avoid storing CHD.

That said, even merchants that only use points of interaction (POI) such as card terminals can also end up with CHD being stored.  I have encountered a number of POIs that were delivered from the processor configured such that the POI was storing full PAN.  Apparently, some processors feel it is the responsibility of the merchant to configure the POI securely even though no such instructions were provided indicating that fact.  As a result, you should contact your processor and have them walk you through the configuration of the POI to ensure that it is not storing the PAN or any other sensitive information.

Then there are the smartphone and tablet solutions from Square, Intuit and a whole host of other mobile solution providers.  While the PCI SSC has indicated that such solutions will never be considered PCI compliant, mobile POIs continue to proliferate with small businesses.  The problem with most of these solutions is when a card will not work through the swipe/dip and the CHD is manually keyed into the device.  It is at that point when the smartphone/tablet keyboard logger software captures the CHD and it will remain in the device until it is overwritten which can be three to six months down the road.  In the case of EMV, the device can capture the PIN if it is entered through the screen thanks to the built in keyboard logger.  As a result, most EMV solutions use a signature and not a PIN.  The reason Square, Intuit and the like get away with peddling these non-compliant POI solutions is that they also serve as the merchant’s acquiring bank and are accepting the risk of the merchant using a non-compliant POI.

The bottom line here is that merchants need to understand these risks and then make appropriate decisions on what risks they are will to accept in regards to the explicit or implicit storage of CHD.

Mobile Payment Processing

The key thing to know about these solutions is that the PCI Security Standards Council has publicly stated that these solutions will never be considered PCI compliant.  Yes, you heard that right; they will never be PCI compliant.  That is mostly because of the PCI PTS standard regarding the security of the point of interaction (POI) for PIN entry and the fact that smartphones and tablets have built in keyboard loggers that record everything entered into these devices.  There are secure solutions such as the Verifone PAYware line of products.  However, these products only use the mobile device as a display.  No cardholder data is allowed to be entered into the mobile device.

So why are these solutions even available if they are not PCI compliant?  It is because a number of the card brands have invested in the companies producing these solutions.  As a result, the card brands have a vested interest in allowing them to exist.  And since the companies offering the solutions are also acting as the acquiring bank for the merchant, they explicitly accept the risk that these solutions present.  That is the beauty of the PCI standards, if a merchant’s acquiring bank approves of something, then the merchant is allowed to do it.  However, very few merchants using these solutions understand the risk these solutions present to them.

First is the risk presented by the swipe/dip device.  Some of these devices encrypt the data at the swipe/dip but not all.  As a result, you should ask the organization if their swipe/dip device encrypts the information.  If it does encrypt, then even if the smartphone/tablet comes in contact with the information, it cannot read it.  If it is not encrypted, I would move on to the next mobile payments solution provider.

The second risk presented is the smartphone/tablet keyboard logger.  This feature is what allows your mobile device to guess what you want to type, what songs you like and a whole host of convenience features.  However, these keyboard loggers also remember anything typed into them such as primary account numbers (PAN), driver’s license numbers and any other sensitive information they can come into contact.  They can remember this information as long as it is not overwritten in the device’s memory.  Depending on how much memory a device has, this can be anywhere from weeks to months.  One study a few years back found that information could be found on mobile devices for as long as six months and an average of three months.

While encrypting the data at the swipe/dip will remove the risk that the keyboard logger has CHD, if you manually key the PAN into the device, then the keyboard logger will record it.  As a result, if you are having a high failure rate with swiping/dipping cards, you will have a lot of PANs contained in your device.

The bottom line is that if you ever lose your mobile device or your trade it in, you risk exposing CHD if you do not properly wipe the device.  It is not that these solutions should not be used, but the purveyors of these solutions should be more forthcoming in the risks of using such solutions so that merchants can make informed decisions beyond the cheap interchange fees.

There are more things merchants can do to keep it simple and I will discuss those topics in a future post.


The Economics Of EMV

There are a lot of people out there that have apparently taken big swigs of the EMV Kool Aid and think that merchants and banks in the United States are all idiots for not believing in EMV.  Well folks, here is EMV by the numbers.  Unfortunately, the best set of complete numbers I could get are from 2009, but I know that the fraud percentages have not radically changed since 2009.

As this example will illustrate, EMV in the US is a non-starter, not because we do not like EMV, but because it makes no financial sense. While I am using Target as the example, these numbers are pretty much what most retailers (large or small) are looking at as they evaluate going to EMV.

  • Target had around $65B USD in revenue for 2009 as reported in their Annual Report.
  • For 2009, card fraud amounted to 0.11% according to a report from the US Federal Reserve Bank of Kansas City report on EMV adoption. For comparison, card fraud in the UK (the best in Europe and the best for EMV countries) is 0.08%, a 0.03% improvement over the US.
  • We know that not all of Target’s revenue is in card transactions but I will estimate that 70% of revenue was card transactions (around $45.5B USD). Then Target has around $50M in losses related to card fraud for the year at 0.11%.  Therefore, assuming a 0.03% improvement in fraud due to implementing EMV, Target is saving around $13.5M USD a year.
  • Estimating between $50M to $100M USD to replace the POS (possibly), terminals and software to support true EMV (for comparison, Target is already spending an estimated $25M to $30M just on new terminals), Target gets a payback on that $13.5M USD savings due to EMV in around four to seven years.

I can tell you from experience that, if a merchant cannot get a three year or less payback, they will not even consider the investment. A two year or less payback is actually preferred and the only sure way for any project to get management’s consideration and approval.

But while the financials for EMV do not add up, there are also other factors that are causing retailers to question a conversion to EMV.

One of the largest is the fact that EMV does nothing to stem the fraud losses from card not present (CNP) transactions. Since most retailers are viewing eCommerce as their next new retail opportunity, the exponentially increasing losses due to CNP fraud does not improve the likelihood of converting to EMV. And with that larger focus on eCommerce and maintaining brick and mortar margins, there is also the concern regarding investing significantly in any changes to those brick and mortar operations that also hold back retailers from transitioning to EMV.

Another consideration is that a lot of retailers just upgraded their terminals a few years back to comply with the PCI PTS requirement. Most retailers like to get at least seven to ten years out of their technology investments. Had Visa and MasterCard played their cards right and coordinated their EMV push with the PTS changes, the US likely would have converted to EMV.

Finally, there are concerns about EMV even surviving given the advent of new payment technologies such as eWallets as well as Bitcoin and other new forms of payments. As a result, a lot of retailers are sitting on the sidelines while technology and payment methods sort themselves out before considering making any investments in new payment process capabilities.

That my friends are the cold, hard facts of why EMV is currently dead on arrival in the US.


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


July 2017
« Jun    

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,854 other followers