Remote PCI Assessment Guidance Issued

At the end of September 2021, the PCI Council released a Guidelines and Procedures document on conducting Remote Assessments for PCI and card brand assessments.  Most of this document is a rehash of previous Council statements and guidance.  However, there is one new element in this document that all QSAs will need to read and comply with and that is the requirement of documenting a feasibility analysis to justify conducting a remote assessment.

Some of the examples the Council gives as valid reasons that an on-site assessment may not be feasible includes:

• Restrictions on the ability to travel or meet in person due to health and safety concerns or government advisories.  We are all familiar with the COVID-19 pandemic and its impact on travel, particularly international travel.  However, I encountered this a while back due to a volcanic eruption in Iceland that cancelled my trip to Europe.  Since we had no way of knowing how long the eruption would cause travel disruptions and we were on a tight timeline, we conducted video conferences rather than travel.
• Geographic locations that are physically inaccessible or difficult to reach.  I personally ran into this situation one several years ago when a data center in Europe that was supposed to be decommissioned before the next assessment remained operational.  The company I worked for had shut down their EU operations and there was no way to justify 16 hours of flight time for a two-hour data center walk through.  We held meetings with the data center operator via video conference and did a virtual walk through.
• Testing required at a location is limited to documentation and interviews and no observations of processes, systems or physical environment apply.
• The entity operates a virtual environment without physical premises or facilities.  This has become more and more common with entities that operate in The Cloud.  Why rent expensive office space when there is not need for it?  This situation only got more prevalent with the pandemic and will likely only increase in the future.

As the Council states in their guidance,

“For many assessments, a combination of onsite and remote testing may provide a suitable balance, as it allows for increased efficiencies in the assessment process while enabling an appropriate level of assurance to be achieved in the assessment result.  For example, documentation reviews can often be performed remotely without significant loss of assurance, whereas observations of processes and environmental characteristics will generally require an onsite review.”

Regardless of whether the assessment fits into one of the bullets above, the Council wants QSAs to formally document their analyses of why the onsite assessment cannot be performed and the risks that may present to meeting the assessment objectives.  This analysis needs to be completed prior to starting any testing and is supposed to be a joint effort between the assessor and the client.

Topics that the Council recommends be addressed include, but are not limited to:

• Confidentiality, security, and data protection requirements.
• Availability and effectiveness of the remote assessment technologies.
• Effects on entity’s personnel.
• Effects on operation support.
• Assessment scope and completeness.
• Quality and reliability of digital evidence.

The Council further states:

“During the analysis, the entity and assessor should identify any challenges and potential risks associated with the remote testing and determine whether it is feasible for testing to be thoroughly completed to produce a high level of confidence in the assessment results.

The results of the feasibility analysis—including the risks and challenges associated with use of the remote testing methods, and any mitigating controls for overcoming the risks and challenges—should be documented and agreed upon by both the entity and assessor. A copy of the feasibility analysis results should be included with the applicable ROC/ROV. Entities and assessors may be required to produce the analysis upon request by the PCI SSC or applicable compliance-accepting entity.”

The key points from that statement above is that: (1) the feasibility analysis needs to be submitted with the ROC/ROV and, (2) if requested by the PCI SSC or compliance accepting entity (i.e., Brand or bank), the QSA is required to produce the analysis.  As a result, this is a non-optional exercise.

The feasibility analyses must document that:

• The assessment is feasible to be fully completed at this time using onsite methods, remote methods, or a combination of onsite and remote methods.
• The assessment is only feasible to be partially completed at this time.
• The assessment is not feasible currently.

According to the guidance, it is only those assessments that are completely feasible that can be conducted.

The Council includes a very important note regarding the analyses.

“The feasibility analysis determines whether the use of remote testing methods is feasible for a particular assessment.  Determining that a remote testing method is feasible does not guarantee that use of the testing method will produce the level of assurance needed for the assessor to reach a finding; this will depend on how the remote testing method is implemented and used, whether the testing can be completed for all applicable components and areas, and whether sufficient evidence is provided for the assessor to make a determination.  Assessors and entities should continue to monitor and evaluate the effectiveness of the remote testing methods throughout the assessment to confirm whether the testing methods are performing as intended and whether additional testing may be needed.”

This concept of “assurance” appears to all be in the eye of the beholder.  Meaning, if the Council, Brands or Banks determine, in their opinion, that the remote methods are not providing appropriate levels of assurance, the ROC/ROV can be rejected.  Not that a lot of banks are going to reject ROCs/ROVs on this, but I can see the Council’s AQM reviews and Card Brands rejecting ROCs/ROVs on analyses that they deem flawed or incomplete.  The AQM process is the most concerning because a QSAC could end up in remediation due to a failure to appropriately document the remote assessment feasibility.

As with most edicts issued by the Council, they should have produced a form for this feasibility analysis so that everyone understands what is required from these feasibility analyses.  Can the feasibility analysis be documented in section 1.2 of the reporting template or is a separate document required?  I would recommend this for the obvious remote assessments of COVID and everything in The Cloud.  I would recommend a separate document for feasibility analyses that are longer in discussion.

Sadly, I foresee a lot of confusion and heartache in the QSAC community as we move through this new requirement.  That is because I see a lot of assessments that are blocked due to COVID travel restrictions or the assessed entity having no physical offices being rejected for “flawed” feasibility analyses when it should just be allowed with no further documentation or discussion.

It will take time to see how this shakes out.

UPDATE 11/29/2021 – I received a comment on this post (see below) and the confusion is beginning. A service provider has had one of their customers request the documentation regarding what is provided in Appendix A of the remote assessment guidance document as well as the remote assessment feasibility study. Since these are ROC documents, there is no requirement from the Council that requires any organization to turn over their ROC to any third party other than their acquiring bank or the card brands. The AOC is the communication document to third parties. If an organization wishes to turn over Appendix A from the guidance, that is the organization’s decision, but it is NOT mandatory nor it is required by the Council.

Advertisement

PCI Dream Team LIVE! Is Coming In October

The PCI Dream Team will be appearing LIVE at the (ISC)² Security Congress in Orlando this Fall, Monday, October 18 through Wednesday, October 20, 2021.   Our session is scheduled for Tuesday, October 19, at 11:45 AM ET/ 1545 UTC.

While we will be live at the conference, you can also attend the conference and our session virtually.  So other than training budget limitations, there is no other good reason you cannot join us.

As usual, we will be taking questions live and via email at pcidreamteam AT gmail DOT com.  We also monitor Twitter if you use #pcidreamteam.

We are expecting our usual lively discussion of all topics PCI and other security standards if time allows.

We really are looking forward to physically seeing people at the conference.

Remote Assessment Guidance Issued

The PCI SSC has issued guidance in response to the Covid-19 pandemic and conducting on-site fieldwork for PCI assessments.  Their blog post can be found here.

Given that governments around the world are saying that this pandemic could be ongoing until the summer, I would suspect that the Council will have to issue better guidance than what is in their latest blog post.  So I would expect more to come on this topic in the coming weeks.

03/19/2020 UPDATES: The Council has set up a Web page to track any Covid-19 updates. Also, remote assessments guidance has been provided and are allowed given the current pandemic conditions. Key is to discuss a remote assessment with the banks and/or brands involved.

The End Is NEIR – More Information And Clarity

Let us try this again, shall we?

I heard recently about a new PCI acronym – NEIR – from a variety of people.  It seems to be that being the PCI Guru, everyone just assumes that I knew what NEIR was about.  I was totally stumped.  I had no idea what it stood for and various internet search engines were worthless, so I contacted people in my network to get educated.

After a number of communications with a variety of contacts, I was able to find out that this acronym is a new service offering from one of the larger QSACs in the United States.  NEIR it turns out stands for Non-listed Encryption Implementation Review.  According to the people I communicated, this review results in a Report of Functionality (ROF).

After posting the original post, I was contacted by the QSAC regarding issues with that original post.  After a number of email exchanges, we realized where we needed clarifications, where there was confusion, and what needed to be corrected.  Based on what I was told by the people I communicated and what the QSAC explained, there is obviously a lot of confusion regarding NEIR.  The QSAC is going back to clarify a few items on their side and I rewrote this post to reflect my new understanding of NEIR.

The first piece of confusion was that NEIR was created by the PCI SSC.  It was not, it was created by the QSAC who then ran it past some people at the Council to make sure they were not doing something wrong.  Why my sources at the Council did not remember it is likely because it did not go against any practices expected by the Council and therefore was forgettable in their minds.  However, in using the word “vetted” in the QSAC’s description of NEIR, it seems to have created an impression with some people that NEIR was somehow officially approved by the Council which was not accurate. The QSAC is addressing that issue going forward.

The second piece of confusion was that NEIR is mandated for PCI compliance.  Where this confusion I am sure comes from is based on what NEIR addresses.  NEIR is a process to assess the implementation of an end-to-end encryption (E2EE) payment solution that has not gone through the P2PE validation process for scope reduction.

As a reminder, if a merchant has an E2EE solution and thus desires P2PE scope reduction for their assessment, then the implementation of that E2EE solution must be performed to ensure it actually protects the payment information and reduces scope.  The results are then shared with the merchant’s processor/bank and the processor/bank must give written approval to the QSA for P2PE scope reduction.

That assessment process is mandatory if a merchant expects P2PE scope reduction.  Every QSA that encounters an E2EE solution must go through this sort of assessment process and then gets explicit approval for P2PE scope reduction from the merchant’s processors and/or banks.  If not performed, then P2PE scope reduction is not allowed for the assessment.

With NEIR, the QSAC has codified that E2EE assessment process for consistency resulting in the ROF for the processor/bank to review and formally approve the scope reduction.  I posted about this sort of process a while back which the QSAC’s representative referenced in our communications.

However, as it unfortunately happens with these sorts of things, communications get bolloxed up and what prospects are told versus what they understand is not one and the same.  This is what I heard all about as I tried to figure out what was going on.  People were inconsistent in what NEIR was about and how it worked and since I did not get any materials from those people due to NDAs, I could not confirm or deny what they were saying was accurate.  The only consistency was that it was required for PCI compliance and that it was the Council that required it.  It took discussions with the QSAC to get to the bottom of all of this and clarify the situation.

So, there you have it.  Now you know about NEIR.  So, if you encounter it, you know what you are dealing with and what it addresses.  Nothing new, just one QSAC’s take on a process to assess E2EE payment solutions for P2PE scope reduction.

Bank Of America Makes NESA Mandatory

Remember the non-listed encryption solution assessment (NESA)?  Probably not because it really didn’t get legs.  That is until now and from an unlikely source – Bank of America (BoA).  QSAs that perform a lot of merchant Report On Compliance (ROC) that go to BoA have likely noticed that BoA have been scrutinizing those ROCs more than before.

This has been particularly true of ROCs that use end-to-end encryption (E2EE) solutions such as Verifone Verishield or First Data TransArmor and you are asking BoA for scope reduction to point-to-point encryption (P2PE).  I ran into this three years ago with a client that was implementing TransArmor at their retail stores.  After much negotiation by my client, they were finally granted P2PE scope reduction and their assessment moved on.

However, at the same client this past year, a shock.  BoA told them not so fast on P2PE scope reduction this year.  As the client and their new QSA found out, sometime in 2018 BoA introduced a whole program to deal with E2EE solutions that now requires a P2PE-QSA to assess the solution and produce a NESA report.  Surprise!

What makes this particularly sad and annoying is that First Data and BoA are joint partners in Bank of America Merchant Services (BAMS) the transaction processing arm of BoA.  BAMS relies on First Data solutions such as TransArmor for processing and securing payment transactions.  But guess what?  Think that your TransArmor solution will get a “pass” from BoA when it was recommended by BAMS?  Think again.  BoA is requiring all non-P2PE validated solutions to go through a NESA.  And that is exactly what this client has, TransArmor from First Data that is a partner in BAMS.

The lesson here is, be prepared as a QSA to deal with a new issue if you have E2EE, you want P2PE scope reduction and your client’s bank is BoA.

The Remote Worker Dilemma

We received the following question during the last PCI Dream Team session back in October.

“We have a call center that sometimes takes a credit card numbers from customers.  Our senior management keeps pushing us to come up with a work-from-home option for some of our call center employees in case of DR and Business Continuity.  We keep telling them that PCI says that all components of such a home setup is subject to PCI standards and thus is impossible, Have any of you seen any solution that would allow this?”

Since that session the Council released the new telephony information supplement that has created a stir in the PCI community.  I wrote about the new information supplement a few weeks back so I will not cover that here, but I will rely on it to answer this question.

First and foremost, remote workers are allowed under the PCI DSS as there are no requirements that prohibit it.  However, there are PCI-related considerations when you want to implement such an approach.

You will obviously need to develop PCI compliance policies, standards and procedures that will support remote working.  If your organization already has policies, standards and procedures for clean desks, secured work area, protection of information, proper handling of sensitive authentication data (SAD) or cardholder data (CHD), then you probably have the bulk of what you need.  You will need somewhere in your documentation to allow for your organization to conduct annual and spot inspections of remote working environments for compliance with organization policies, standards and procedures.

If you do not have those policies, standards and procedures, then you will need to get those published, approved and all employees and contractors to formally acknowledge them.  Most organizations’ policies, standards and procedures work just fine for corporate environments but do not consider the situation when workers are not in a corporate facility.  As a result, it is not unusual to see organizations develop policies, standards and procedures that take into account that the remote workers’ working environment might not necessarily be as secure as those at a corporate controlled office.

The annual inspection can consist of the remote worker taking a picture of their work environment and filling out a form that ensures the remote worker is complying with relevant organizational policies, standards and procedures as related to remote working.  I have clients that have remote workers fill out the relevant PCI SAQ depending on their remote worker environment.  In all cases, the employee signs the form/AOC stating that they are compliant with all relevant policies, standards and procedures.

It is when the organization has questions, issues or concern with a remote worker is when the spot inspection clause becomes useful.  The spot inspection capability allows organization management or an auditor to go to the remote worker’s location and personally examine the work area to ensure that it complies with all policies, standards and procedures.

With the paperwork out of the way, let us now discuss the technical challenges related to remote workers.  The goal here is to minimize the PCI scope of the remote worker’s configuration.

The easiest way to do this is using a point-to-point encryption (P2PE) validated solution or an end-to-end encryption (E2EE) solution for the keying of SAD/CHD.  Of course, this means that you will have to ensure that your application will work properly with a P2PE/E2EE solution which further means not allowing SAD/CHD to be keyed through anything other than a P2PE/E2EE validated terminal also referred to as the point of interaction (POI).  This can also mean pairing the P2PE/E2EE solution with tokenization if your application is expecting CHD back at the end of the transaction.

But P2PE/E2EE only addresses the transaction, not the conversation that results in the transaction.  To reduce costs of remote workers, organizations typically implement a softphone.  Softphones are great.  However, they result in a PCI scoping problem.  As a reminder, when a telephone system is used for having conversations involving SAD/CHD, it puts that system and networks in the cardholder data environment (CDE) also known as a Category 1 system.  As a result, any other system that connects to the telephone system is now also part of the CDE.  Since a soft phone cannot be readily logically or physically segmented from the workstation it connects, it drags the workstation into PCI scope regardless of whether or not SAD/CHD is discussed.

The solution to the softphone issue is to use a physical VoIP phone with a headset.  But it is not as simple as just swapping in a physical phone for the softphone.  That physical phone needs to be on a logically or physically segmented network that does not include any devices that you desire to be out of PCI scope.  It is that segmentation that drives up the cost of the remote worker configuration because you now need to have a managed network device to allow for separate VLANs or physically separate network connections.  Not impossible, just costlier than delivering a cable/DSL modem with four Ethernet ports to the remote worker’s location and being done.

As a result of all of this, it is not unusual for organizations that allow for remote workers that need to be PCI compliant to supply those remote workers with a US Department of Defense compliant document shredder, computer or workstation, router, network switch, display(s), keyboard(s), secure POI(s), telephone(s) and any other equipment necessary to ensure compliance with the PCI standards.

In addition to this, there may be other requirements due to the European Union’s General Data Protection Requirement (GDPR), Health Insurance Portability and Accountability Act (HIPAA) or other security or privacy regulations or requirements.

The Requirement 3.2.1 – 3.2.3 Not Applicable Debate

When v3.2 of the ROC Reporting Template came out the QSA/ISA community noticed that requirements 3.2.1 – 3.2.3 could no longer be marked as ‘Not Applicable’.

The rationale the Council gave when they explained why they disallowed ‘Not Applicable’ for these requirements is that they wanted QSAs/ISAs to have to explain what procedures they had followed to confirm that organizations were not storing sensitive authentication data (SAD) in the form of track data, card verification values or PIN blocks.

The push back from QSAs and ISAs was to ask how that was relevant when an organization’s card processing could not come into contact with such information as when P2PE had been implemented?

The Council has long stated that for Level 1 merchants that have, for example, implemented a P2PE solution, they should follow the requirements in SAQ-P2PE to fill out their ROC and mark any requirements not in the SAQ-P2PE as “Not Applicable.  The merchant uses a P2PE validated solution and the requirement is not relevant.”

This Council guidance resulted in the question at the 2016 Community Meeting Assessor Session, “How do you do that for requirements 3.2.1 – 3.2.3 when they cannot be marked ‘Not Applicable’ and do not appear in SAQ-P2PE?”  “Good question.  We will have to get back to you.”, the Council told attendees.

Well, here we are two years and a new version later and these requirements still cannot be marked as ‘Not Applicable’.  A number of people texted me at this year’s Assessor Session to bring this issue up again, but I was tired of arguing and just let it go.

The more I have thought about it, the more I regret not bringing this issue up because it needs to be addressed.

So, if someone attending the Assessor Session at the European or APAC Community Meeting would like to bring this question up, I would appreciate it as would a lot of the QSA/ISA community.

2018 North American PCI Community Meeting Thoughts

It was an interesting time in Las Vegas this year.  Part of that is due to the fact that we are in Las Vegas.  But part of it was that the Community Meeting seemed to be devoid of the usual anticipation for the Community Meeting and expected pronouncements.  While there were announcements for various standard updates, these were well anticipated and were not a surprise.  Some of the slide decks have been released, but others will not be available until the European Community Meeting is held in a few weeks.

While there were a number of good presentations this year, in my very humble opinion, the best session was the Assessor Session at the end of the meeting.  The good news this year was that a lot of QSAs and ISAs made sure to stick around for this session.  There were a number of good questions asked after the Council’s presentation, but I will wait for the Council’s transcript to be published before weighing in on those.

As in years past, the Council had a presentation at the start.  The following are highlights from that presentation.

AQM Program Highlights

As usual, the AQM team did a bang-up job pointing out common issues found in the various assessment types they review.

On the PA-DSS side of the ledger, a lot of PA-QSAs are having issues with requirement 5.1.6.b regarding application least privilege.  The Council clarified that what they are looking for in this requirement is proof that the application does not run as ‘root’, ‘administrator’ or some other default privileged account in order to run properly.

For P2PE assessments, there have been issues regarding when a double length 3DES key can be used.  The Council explained that a double length 3DES key is only allowed when using derived unique key per transaction (DUKPT).  All other uses must be triple length keys to be in compliance with P2PE.

Apparently, QSAs and their QA minders are totally missing what is meant by “describe how”.  When describing “how” a QSA must describe all of those procedures used to determine the requirement was satisfied as well as how those procedures prove the requirement was met.

QSAC QA manuals still are not covering topics such as evidence retention and destruction, security incident response plans and code of conduct policy.  The Council reminded everyone to make sure all topics in the QSA Qualifications Requirements document are covered.

Compensating controls were a continuing problem area and that should not be a surprise.  I am constantly fascinated when I receive a ROC for proof of PCI compliance performed by another QSAC and get to see what passes for a valid compensating control worksheet (CCW) at other firms.  Apparently ‘intent and rigor’ of the requirement and ‘above and beyond’ are foreign phrases to a lot of QSAs.  Never mind the fact that the controls used, tested and maintained are usually vague in description.  The Council pointed people to their Portal for remedial training of QSAs that cannot comprehend writing a CCW.  I have written a number of posts on compensating controls.  If you want to write good CCWs, start here for the most current post and it will point you to prior posts.

The Council got some interesting questions from QSAs over the year.  The first one is one that a lot of clients ask us, “Do you really have to come onsite?”  Yes, an onsite visit by the QSA is actually required.  However, how long a QSA needs to be onsite can vary from as little as a couple of days for a long-time client to a week or more for a new client.  Onsite visits can be supplemented by video meetings when needed.  Not unusual these days when a client has worldwide operations and not everyone is located at headquarters or will not be available when the QSA is onsite.

The other question was regarding ROC and AOC dates.  How people keep messing these up is beyond me, but as with the CCWs, I see a lot of ROCs and AOCs out of other firms where the dates on the documents are not consistent.  Basically, the last thing any QSAC should do is to set all of the dates in the ROC and AOC to match as part of their document finalization processes.  That way you will avoid this problem.

There was a brief discussion of the Software Security Standard (S3) that will replace the PA-DSS.  Most of the discussion revolved around the proposed timeline.  The standards themselves will be published sometime before year end.  Reporting materials will be published around mid-2019 with training commencing in the Fall of 2019.  The big deadline is that PA-DSS Reports On Validation (ROV) will only be accepted through mid-2020 requiring all reports going forward to be under the S3.  That will mean that by mid-2022, all PA-DSS validated applications will move to “Acceptable for Pre-Existing Deployments”.

Finally, SSL and early TLS got a discussion.  Somehow the word has not gotten around that if a company still uses SSL and/or early TLS, there must be a compensating control developed for the relevant requirements since Appendix A2 no longer exists in v3.2.1 of the DSS.  They also reminded everyone that having SSL or early TLS is NOT an automatic fail.  However, vulnerability scans will have to have explanations developed justify the use of the protocols as well as what is done to mitigate their use.

Card Production Security Assessor Program

If you were not aware, the PCI SSC took over the various card brands’ card production programs and created a single common program similar to what the Council did with the Data Security Standard back in 2006.

In response the Council is creating a new assessor program in 2019.  Card Production Assessor Companies (CPAC) will not need to be existing QSACs nor will assessors need to be QSAs.  The new assessor training program will be rolled out next year for this standard.  The Council did note that existing card production assessors will be somehow recognized by the new program but did not specify how that recognition would be implemented.

As with QSACs and QSAs, the Council will maintain a database of CPACs and qualified card production assessors.

PIN Assessor Program

As with card production, the Council has also been responsible for PIN standards for a few years now.  As a result, the Council is developing a program for creating PIN Assessor Companies and PIN Assessors.

There will be no need for the PIN Assessor Company to be a QSAC nor will assessors be required to be QSAs.  This program will also start in 2019.

Global Executive Assessor Roundtable (GEAR)

This is a new group that was established this year.  Its role is to provide a direct communication channel between the PCI SSC and 20 qualified security assessor companies’ (QSAC) senior executive leadership.  This group met for the first time a few days before the start of the Community Meeting.  Each member of GEAR serves for a two-year term.

The 20 QSACs on the GEAR are:

• @sec
• Advantio
• Coalfire
• Control Case
• Foregenix
• IBM Security
• isec
• K3DES
• nccgroup
• Protiviti
• PSC
• RSM
• Security Metrics
• Shellman
• SISA
• Sysnet
• Trustwave
• UL
• usd
• Verizon

As usual, it was great catching up with everyone and meeting new Guru fans.  I really appreciate all of the great comments about the blog.  Even though I see the statistics for the blog, it still amazes me how many people read it and appreciate it particularly when you meet so many of them in person.  It is very humbling.

Hopefully I will see you all next year in Vancouver.

P2PE Versus E2EE Revisited

It has been almost four years since I wrote the original post.  I went back and reread the original and realized it needed a rewrite to make the comments accurate and current.  Point-to-point encryption (P2PE) and end-to-end encryption (E2EE) are a key part to merchants minimizing their PCI scope (the other technology is tokenization) to the maximum.  However, I continue to encounter a lot of organizations that are confused about the difference between the PCI SSC’s P2PE certified solutions and E2EE solutions.  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, SSH and TLS.  In transaction processing, E2EE solutions pre-date P2PE by a number of years as numerous transaction processors and point of interaction (POI) vendors had E2EE solutions before the publication of the P2PE standards.

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 originally used the 56-bit data encryption standard (DES) encryption algorithm but was updated to 168-bit 3DES and later to AES.  While DES is 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 – a time consuming task given the usual large transaction volumes.  While the cloud could be leveraged to perform this decryption rapidly, it would be too costly an effort for the data retrieved.  As a result, DUKPT using DES is still technically considered a secure method of encryption although it is never recommended for use.  3DES and AES are now the more commonly implemented algorithms with AES being the preferred solution if supported by the POI.

One of the big changes with v2 of the P2PE standard was to simplify the certification process which vendors complained was overly complicated and cumbersome in v1.  As a result, the Council responded by simplifying the certification process by adopting a more modular approach.

The other big change was to allow merchants to be in control of key management.  The key management change was driven by P2PE vendors who were finding that large merchants needed to manage their POI encryption keys because they desired to do their own transaction switching between processors.  As a result, large merchants were implementing E2EE solutions rather than P2PE solutions so they could perform encryption key management.

The Council then came up with the Non-Evaluated Solution Assessment (NESA) program a few years ago.  The idea was that P2PE-QSAs would assess the E2EE solutions and produce a report so that merchants could more readily obtain P2PE scope reduction from their banks.  One of the reasons that NESA never caught on was that the Council never really created and shared a good definition of what a NESA report would contain for proof and the format.  QSAs have never had a clear definition of what, if anything, was required to be reported.  As a result, how was a QSA to rely on a document that had no definition?  But what the Council really missed was the fact that most E2EE solutions are approved by the acquiring bank because they are offering it to their customers.  Since the bank determines whether a merchant gets P2PE scope reduction with E2EE solutions, there really was no need for the NESA program.  Never mind the fact that none of the card brands mandated the NESA process.

One of the biggest issues I encounter over E2EE is that merchants believe that E2EE solutions are not acceptable for reducing PCI scope.  That is because the key difference between P2PE and E2EE is that a P2PE solution gives immediate PCI scope reduction as long as it is properly implemented.  A QSA can reduce PCI scope as long as the P2PE solution is implemented according to the P2PE solution’s Implementation Guide (IG).  The acquiring bank’s approval is not required.  That reduction in scope reduces the amount of testing a QSA is required to perform to those requirements in the SAQ P2PE.

To get P2PE scope reduction with an E2EE solution requires a bit more effort, but it does not have to be extensive.  In my experience, contacting a merchant’s acquiring bank can be all a merchant needs to do.  I remember being on a conference call with a client’s acquiring bank to discuss scope reduction for their E2EE solution.  The bank’s representative inquired as to why the call was needed because the E2EE solution was provided by the bank.  I stated that I needed a formal statement for my work papers indicating that the bank approved of my client’s P2PE scope reduction.  The person laughed, made a comment about how silly PCI can be and then emailed me the P2PE scope reduction approval.

A QSA should still do some investigation work of the E2EE solution to ensure it has been properly implemented regardless of what the bank might say.  Those efforts should include:

• Network packet captures at key points on the customer’s network to ensure that the packet remains encrypted. Those captures should include comparing the payloads to ensure decryption/encryption does not occur along the network path.  This can be done at the customer’s testing lab.
• If the POI is not stand alone and connects to a PC via USB, collect a packet capture of the USB connection using Wireshark’s USB capture solution or a similar solution. This can be done at the customer’s testing lab.
• Use the E2EE solution’s Implementation Guide (IG) to ensure that the E2EE solution was implemented according to the vendor’s instructions. Conduct a visit to a sample of retail locations to ensure that those locations match the configuration and connectivity you observed in the testing lab.
• If the customer is managing the E2EE solution keys, investigate and document the key management to ensure they comply with the key management requirements in 3.5 and 3.6 of the PCI DSS and requirements in Domain 6 of the P2PE Solution Requirements and Testing Procedures v2.
• If the customer is managing the POI key injection process, investigate and document that process to ensure the POI remain secure throughout the process from injection to delivery at the retail location.

These E2EE testing efforts are typically negligible, so any assessment savings over using a P2PE certified solution are limited at best based on my experience.

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.  This is why a lot of Chief Financial Officers are a bit put off by P2PE.  For some merchants, that could be a costly proposition and make any switch not worth the effort.  The P2PE switch limitation is a tad bit less with E2EE but even then you will be limited to processors that support your E2EE solution and the conversion will require reinjection of POI keys by the new processor which might not be as seamless or even impossible to perform thus resulting in getting new POI.

If your organization is looking at P2PE versus E2EE, I would not necessarily give the advantage to P2PE.  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.

What Are You Really Interested In?

As a QSA, we hear this comment all of the time.

“PCI is all about compliance, not security.”

The implication being that the person talking is interested in actually securing their environment not just being PCI compliant.

Yet as the conversation goes on, we get into esoteric discussions regarding scope and how scope can be minimized.  Not necessarily a bad thing, but as these discussions continue, an underlying theme becomes apparent.

This conversation eventually leads to the QSA asking, “What are your drivers that are making you so concerned about minimizing scope?”

The inevitable answer is, “Because, we want to minimize the cost of and/or difficulty in implementing (in no particular order) information security, increasing information security personnel, how many devices we vulnerability scan and penetration test, critical file management tools, anti-virus licenses, devices needing log aggregation and analysis, [insert your security tool/product/device/appliance/widget here].”

It is at that point it becomes painfully obvious that the organization is not at all interested in security.  In fact, they do not give a damn about security.  Their only interest is in checking off the PCI compliance box and moving on to the next annoying compliance checkbox on their list.

I am sure a lot of you are questioning, “How can you be saying this?”

Because, if the organization were truly interested in security, all of the things they mention in their minimization discussion would already be installed in their production environment, if not QA and test environments.  That is right.  They would already be installed and not just on the PCI in-scope stuff.  It would already be installed everywhere in those environments.

Why?

Because all of these security tools and methods are part and parcel of a basic information security program that follows information security “best practices”.  They are not special to PCI, they are required for any successful information security program such as HIPAA, FFIEC, FISMA, HITRUST, etc.

People seem to think that the PCI SSC and the card brands came up with the PCI DSS requirements by arbitrarily pulling the requirements out of thin air.  In fact, I have had people insinuate that the PCI standards are just there for the banks to be mean to merchants and extract more money from them.

But in actuality, the PCI standards come from a lot of recognized sources including the US National Institute of Standards and Technology (NIST) security standards and guidance, US Department of Defense (DoD) security standards and guidance, as well as “lessons learned” from the card brands’ cardholder data breach forensic examinations and working with information security professionals sharing their knowledge of what are the minimum, basic “best practices” required to secure data.

But the key words here are ‘minimum’ and ‘basic’.

Because guess what?  If you want true security (remember that thing you supposedly wanted when we started), then you have to go beyond the PCI DSS requirements.  Hear that people?  If you want true security, your organization must go BEYOND the PCI DSS requirements.  Organizations are complaining about doing the basics.  Imagine what their complaints would be like if they had to do true security?  They would be throwing a tantrum that would be easily heard around the world.

Want actual proof that organizations are not doing the basics?

Read the Verizon Data Breach Investigation Report (DBIR) or any of the dozens of data breach reports issued annually by forensic analysis firms.  They all read the same; year after year after nauseating year.  Organizations cannot consistently execute even the basic security requirements specified in any security standard.  Even more disheartening is the fact that it is the same vulnerabilities and mistakes that are the root cause of the vast majority of breaches.

QSAs still get complaints from organizations about the PCI DSS being too difficult and costly to implement and maintain.  Yet these same organizations have the gall to say that PCI is NOT about security.

So, before you go and tell your QSA that PCI is all about compliance, think long and hard about that remark and why you are saying it.  Odds are you are saying it to look good, make a good impression with your QSA, show them that you are a true security professional and that your organization wants to be secure.

Think again.  The truth will eventually come out.  One way or another.