Archive for the 'PCI P2PE' Category



13
Feb
16

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.

SSL/Early TLS

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.

Miscellaneous

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.

03
Oct
15

Another Annual Community Meeting

Another year has come and gone and so has another North American PCI Community Meeting. This one held in the beautiful city of Vancouver, British Columbia, Canada.

I have to say that the new leadership of the Council is showing. I heard many comments from attendees that this year’s conference was better than in years past.

The Good

  • The ‘Mobile Forum Roundtable Discussion’ was probably the best session of the conference. That is based on comments from the attendees of this session as well as the comments from other conference attendees that went to the competing sessions. If the Council is looking for how to structure future sessions, this is the format. Participants sat at numbered tables and then each table was given a question on the topic of mobile payments to discuss for half of the session. The last half of the session was a representative from each table presenting the findings from those table discussions. I think the Council’s Mobile Working Group, of whom some members were present, as well as the other attendees of this session learned a lot in an hour and a half.
  • There were two notable sessions regarding point-to-point encryption (P2PE) that had nothing to do with P2PE. One was given by First Data regarding TransArmor and the other was given by Caesars International regarding Shift4. Neither of these end-to-end encryption (E2EE) solutions are P2PE validated. In years past, these sessions would never have occurred. Apparently the new leadership at the Council felt it was important to have their stories told to the Community Meeting participants as a more secure way of conducting transactions even though neither is a P2PE solution. I commend the Council for their foresight in holding such sessions.
  • Brian Krebs’ Keynote on Thursday was not what I was at all expecting. I expected Brian would mostly rehash stuff out of his latest book as most writers do at these sorts of events. But it was a very informative and enlightening session with a lot of good information. For those who regularly read his blog, a lot of the stories he gave we had already heard but not with the personal touches he gave them. If anything, people walked away with a better understanding of why card data is sought after by the underground.
  • As always it was great to get together with everyone involved in PCI and meet a lot of you. The nightly receptions were excellent as were the session breaks. It always amazes me how many people just walk up and introduce themselves to me at these meetings. I really appreciate the fact that so many of you find the blog so useful as well as providing people with a voice in sharing frustrations with PCI and the process. Thank you to all of you that read this blog and find it useful.

The Not So Good

  • The Thursday “TED Talks” format was so-so. While it was definitely the talk at lunch and afterwards at dinner, it was not viewed as a highlight. As I coalesced the comments I heard, I do not think it was not the format as much as not all of the topics presented belonged in such a format. For anyone that has seen or been to TED Talks, they are very, very high energy and involve a passion for a topic that was not completely present in those Thursday sessions. If this is a format the Council wants to use going forward, then the topics are going to have to have a much higher energy to them and be much more important to discuss.
  • I had to chuckle at the vendor booths that were pushing their “silver bullet” solution for PCI compliance. There were only a very few of these “snake oil salesmen” present, but there they were saying they could put parts of your environment completely out of scope for PCI compliance. I thought we were long past such claims, but apparently not.
  • As with any such event, I saw a lot of people that I really wanted to talk to and just did not get the chance to catch up with them.
  • I unfortunately ended up with a number of client and emergency meetings I needed to attend during the conference. As a result, I had a few interruptions and could not attend a number of the sessions I really wanted to attend.

The Notably Missing

  • Professional Breakout Sessions were missing. This is a PCI conference that brings together qualified security assessors (QSA), internal security assessors (ISA), approved scanning vendors (ASV) and participating organizations (PO). Yet, there were no breakout sessions for those participants to meet with anyone from the Council. You would think that getting feedback from each of these important groups would be important to the Council. Other than these groups going individually to the Council’s office on “Card Brand Row”, there was no program for these important constituents to get together and voice their concerns. One would think this is a key part of why you hold such an event yet this piece was missing.

Overall though this year’s Community Meeting was probably one of the better ones I have attended.

See you all next year in Las Vegas.

15
Nov
14

Security Or Checking A Box?

“Better to remain silent and be thought a fool than to speak out and remove all doubt.” Abraham Lincoln

What is your organization interested in?  Security or checking a box?

Not surprisingly, most people answer “security” and then go on to prove with their actions and words that they are only interested in checking a box.

For all of you out there that argue ad nausea about the meaning of PCI DSS testing requirements and the requisite documentation are interested in one thing and one thing only; checking a box.  I am not talking about the few that have honest differences of opinion on a few of the requirements and how a QSA is interpreting them and assessing them.  I am talking about those of you that fight constantly with your QSA or acquiring bank on the process as a whole.

If you were to step back and listen to your arguments, you would hear someone that is splitting hairs in a vain attempt to avoid having to do something that would improve your organization’s security posture.  In essence, you want to only be judged PCI compliant, not actually be secure.

To add insult to injury, these are also typically the people that argue the most vehemently over the fact that the PCI DSS is worthless because it does not make an organization secure.  Wow!  Want to have your cake and eat it too!  Sorry, but you cannot have it both ways.

Everyone, including the Council, has been very clear that the PCI DSS is a bare minimum for security, not the “be all to end all” for securing an organization.  Organizations must go beyond the PCI DSS to actually be secure.  This where these people and their organizations get stumped because they cannot think beyond the standard.  Without a detailed road map, they are totally and utterly lost.  And heaven forbid they should pay a consultant for help.

But I am encountering a more insidious side to all of this.  As you listen to the arguments, a lot of you arguing about PCI compliance appear to have no interest in breaking a sweat and doing the actual work that is required.  More and more I find only partially implemented security tools, only partially implemented monitoring and only partially implemented controls.  And when you dig into it as we must do with the PCI assessment process, it becomes painfully obvious that when it got hard is when the progress stopped.

“It’s supposed to be hard. If it wasn’t hard, everyone would do it.” Jimmy Duggan – A League Of Their Own

Security guru Bruce Schneier was speaking at a local ISSA meeting recently and when asked about why security is not being addressed better he stated that one of the big reasons is that it is hard and complex at times to secure our technology.  And he is right, security is hard.  It is hard because of our poor planning, lack of inclusion, pick the reason and I am sure there is some truth to it.  But he went on to say that it is not going to get any easier any time soon.  Yes, we will get better tools, but the nature of what we have built and implemented will still make security hard.  We need to admit it will be hard and not sugar coat that fact to management.

Management also needs to clearly understand as well that security is not perfect.  The analogy I like to use is banks.  I point out to people the security around banks.  They have one or more vaults with time locks.  They have video cameras.  They have dye packs in teller drawers.  Yet, banks still get robbed.  But, the banks only stock their teller drawers with a minimal amount of money so the robber can only get a few thousand dollars in one robbery.  Therefore to be successful, a robber has to rob many banks to make a living which increases the likelihood they will get caught.  We need to do the same thing with information security and recognize that breaches will still occur, but because we have controls in place that minimizes the amount or type of information they can obtain.

“There’s a sucker born every minute.” David Hannum

Finally, there is the neglected human element.  It is most often neglected because security people are not people, people.  A lot of people went into information security so that they did not have to interact a lot with people – they wanted to play with the cool tools.  Read the Verizon, Trustwave, etc. breach analysis reports and time and again, the root cause of a breach comes down to human error, not a flaw in one of our cool tools.  Yet what do we do about human error?  Little to nothing.  The reason being that supposedly security awareness training does not work.  Security awareness training does not work because we try to achieve success only doing it once per year not continuously.

To prove a point, I often ask people how long it took them to get their spouse, partner or friend to change a bad habit of say putting the toilet seat down or not using a particular word or phrase.  Never in my life have I ever gotten a response of “immediately”, “days” or “months”, it has always been measured in “years”.  And you always get comments about the arguments over the constant harping about changing the habit.  So why would any rational person think that a single annual security awareness event is going to be successful in changing any human habits?  It is the continuous discussion of security awareness that results in changes in people’s habits.

Not that you have to harp or drone on the topic, but you must keep it in the forefront of people’s mind.  The discussion must be relevant and explain why a particular issue is occurring, what the threat is trying to accomplish and then what the individual needs to do to avoid becoming a victim.  If your organization operates retail outlets, explaining a banking scam to your clerks is pointless.  However, explaining that there is now a flood of fraudulent coupons being generated and how to recognize phony coupons is a skill that all retail clerks need to know.

  • Why are fraudulent coupons flooding the marketplace? Because people need to reduce expenses and they are using creative ways to accomplish that including fraudulent ways.
  • What do the fraudulent coupons do to our company? People using fraudulent coupons are stealing from our company.  When we submit fraudulent coupons to our suppliers for reimbursement, they reject them and we are forced to absorb that as a loss.
  • What can you do to minimize our losses? Here are the ways to identify a fraudulent coupon.  [Describe the characteristics of a fraudulent coupon]  When in doubt, call the store manager for assistance.

Every organization I know has more than enough issues that make writing these sorts of messages easy to come up with a topic at least once a week.  Information security personnel need to work with their organization’s Loss Prevention personnel to identify those issues and then write them up so that all employees can act to prevent becoming victims.

Those of you closet box checkers need to give it up.  You are doing your organizations a huge disservice because you are not advancing information security; you are advancing a check in a box.

11
Sep
14

2014 North American PCI Community Meeting

Another year has come and gone and so has another PCI Community Meeting.  There were a number of interesting events at this year’s meeting.  Some I will cover here and some I still have to digest and determine what they really mean.

Good Bye Bob

This year’s meeting is the last one for the PCI SSC’s current General Manager, Bob Russo.  Over the years, Bob has been a good sport and has been a cowboy and other characters.  This year’s community meeting was no exception.  At Wednesday night’s networking event, Bob showed up as Gene Simmons’ brother decked out in silver colored platform boots, black tights, leopard spotted top, long black hair and doing his best to show off his tongue.

A lot of us over the years have pilloried Bob for various edicts and clarifications as he was the leader of the Council.  However, if we step back, Bob got the PCI SSC off the ground and took on the thankless task of combining the disparate security standards of the five card brands and giving us the common set of standards we have today.  As well as then asking us to do our best to ensure that those standards were followed.

Even though I have been critical at times of Bob, he has always been pleasant and cheerful to me and others at the community meetings and other events where he was present.  Bob recognized that there are always some of us in the crowd that are very passionate about security and tried to assist us in channeling that passion.

Bob stated that he will be doing a “Goodbye Tour” to the other community meetings this year, so make sure to thank him for his efforts, shake his hand and say your goodbyes at whatever meeting you are able to attend.

P2PE v2

The first versions of P2PE were lambasted for being pointless and the number of solutions certified, now at six, has somewhat proven that the newest of the PCI standards needed some work.  As a result, in November 2014 we will receive version 2 of the P2PE standard.  According to people I spoke with at the meeting that have seen the new version, the new standard should be much better. Is it perfect, no. But it supposedly is a better version than the originals.

The most notable change to the standard is the approach the Council has taken.  Based on the presentation made, they seem to abandoning the complete end to end model and are moving to a component approach based on how the solution will be implemented.

But the huge change to the standard is that a certified P2PE solution can be managed by a merchant without a third party.  That is, merchants can manage the encryption keys.

It will be interesting to see just how much the standard has changed since its last iteration only a year ago.  But most of all, it will be interesting to see how the new implementation approaches will work.

SAQs

The biggest clarification to come out of the community meeting on SAQs is the Council’s and card brands’ endorsement of using multiple SAQs for documenting compliance with the PCI standard versus doing an SAQ D.

This situation occurs when a merchant has multiple payment channels such as with merchants that have retail stores using traditional card terminals (SAQ B or B-IP) and an eCommerce presence that is outsourced (SAQ A or A-EP).

The other area of discussion that seemed to cause a bit of a stir was related to Web sites that use redirects or iFrames for payment processing.  The reason for this contention is the result of claims from vendors of these sorts of payment solutions in the past that claimed that their solutions placed merchants out of scope for PCI as it related to their eCommerce operation.

Ever since the issuance of the eCommerce information supplement in January 2013 and with the recent issuance by Visa of their eCommerce guidance, the outsourcing world has been buzzing about the implications.  Merchants of course have been going back to their eCommerce outsourcers and complaining about the fact that their eCommerce is no longer out of scope.

Reliance On Other’s Work

My final comment will be related to a question I asked at the Open Forum session on Wednesday.  We have been getting push back from our larger clients on our limited use of their internal audit work, SSAE 16 reports, ISO 27K audits and similar work, if we used it at all.  The driver is that clients want to minimize the amount of disruption to their personnel by all of the audits and assessments that are occurring these days.  This prompted me to ask the question at the Open Forum as to the Council’s advice on reliance on other auditor’s work to reduce sampling.

The answer I received was, “No, absolutely not.”  Quickly followed by, “Of course, I mean other auditors, not other QSAs and PA-QSAs.”

This blunt answer apparently shocked the audience as the people on stage reacted to that shock as well.  The people onstage then backed off saying that the Council would have to take the issue back and discuss it.

After asking this question I was approached by a number of people thanking me for bringing up the topic.  The bottom line is that organizations are audited and assessed out.  Most feel like one audit/assessment ends and another one begins.  But the truly annoying thing is that there are certain portions of all of these audits/assessment that cover the same ground over and over and over again such as with physical security, access controls and end user management.  Handled properly, it would not eliminate all testing, but it would definitely reduce the amount of testing and also reduce sample sizes.

But a very telling comment came from a member of the American Institute of Certified Public Accountants (AICPA) who told me that the AICPA has repeatedly tried to meet with members of the PCI SSC to discuss the SSAE 16 standard and how it could be used to reduce a QSA’s work only to be rebuffed by the Council.

Organizations would be more willing to go through PCI assessments if work done by their internal auditors as well as outside auditors could be leveraged to simplify their lives, not complicate them.  This will only become more important as the Council pushes organizations to adopt business as usual (BAU).

If I had one important take away for the Council to work on, it would be to work with other standards bodies such as the AICPA, ISO, FFIEC and the like and work toward providing guidance to organizations on how to use internal and external audit reports.

24
Aug
14

P2PE Versus E2EE

I have been encountering a lot of organizations that are confused about the difference between the PCI SSC’s point-to-point encryption (P2PE) certified solutions and end-to-end encryption (E2EE).  This is understandable as even those in the PCI community are confused as well.

E2EE is the generic terminology used by the IT industry to describe any solution that encrypts communications from one endpoint to another endpoint.  Key management of the encryption can be done by any party that has an endpoint such as a merchant or a service provider.  Examples of E2EE include IPSec, SSL and TLS.

One of the most common E2EE solutions used by merchants is derived unique key per transaction (DUKPT) also known as “duck putt”.  DUKPT is commonly used in the convenience store and gas station industries to encrypt sensitive authentication data (SAD) from the gas pump to the merchant or processor.  DUKPT uses the 56-bit data encryption standard (DES) encryption or triple DES (3DES) algorithms.  While DES and 3DES 56-bit and 112-bit are no longer considered secure, because DUKPT uses a unique key for every transaction, it means that every transaction has to be individually broken to gain access to the data.  While using the cloud could be leveraged to perform this rapidly, it would be too costly an effort for the data retrieved.  As a result, DUKPT is still considered a secure method of encryption.

P2PE is a subset of E2EE.  This is because the major difference between P2PE and E2EE is that P2PE does not allow the merchant to be a manager of the encryption keys.  Under the P2PE standard, only the transaction processor or other third party is allowed to perform key management.  The merchant is never allowed to perform encryption key management under the P2PE standard.  As a result, DUKPT can be used by both P2PE and E2EE solutions.  However, under P2PE, the key management must be done by a third party, not the merchant.

While third party key management is typically acceptable for small merchants, this does not work for merchants that switch their own transactions to various processors as do mid-sized and large merchants.  That does not mean that E2EE solutions are not acceptable for reducing PCI scope.  As with PA-DSS certified applications, P2PE certified solutions can be accepted by a QSA as long as they are implemented according to the P2PE implementation guide which can reduce the amount of testing a QSA is required to perform.  In my experience, P2PE versus E2EE testing efforts are typically negligible, so any so-called savings are limited at best.

The huge downside to P2PE for merchants is that once you decide on a given P2PE solution, you are pretty much stuck with it and the processor providing it.  That is because most processors offering P2PE are only offering one P2PE solution.  As a result, if a better deal comes along for processing your transactions, you will likely have to replace your terminals and possibly other equipment to switch to the new processor.  For some merchants, that could be a costly proposition and make any switch not worth the effort.

So if your organization is looking at P2PE versus E2EE, I would not necessarily give an advantage to P2PE over E2EE.  Just because an E2EE solution is not P2PE certified does not mean it is not secure.  It only means that the vendor did not believe that the P2PE certification was worth the effort.

02
Nov
13

P2PE Revisited

David Froud is on a roll.  Tenable’s Jeffrey Man wrote a post regarding point-to-point encryption (P2PE) and it apparently got the juices flowing.

I have discussed P2PE (known to almost everyone else as end-to-end encryption or E2EE) a number of times (see my Post Series References page).  Also see my post on What Happens Once Merchants Get Rid Of Cardholder Data to understand how the risks will shift and that the terminal becomes a large attack point.  This is why we need to get to some sort of single use code for a payment which is easily handled with today’s smartphones.

Read the posts and decide.  I think you will find that they both make compelling cases for why P2PE certification is a non-starter and is really not needed.




November 2021
M T W T F S S
1234567
891011121314
15161718192021
22232425262728
2930  

Months