An Inadvertent Service Provider

A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions.  QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.

The Situation

As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations.  These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses.  Of course, all of these third parties accept payment cards for their services and need a way to process those cards.  Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors.  Thus, bringing that network and everything attached to that network into scope for PCI compliance.

As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant.  The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope.  But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.

But it can and does get worse.  I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.

What Do You Do? Option 1 – Get Out Of Scope

There are some ways to get out of scope, but these can be complex and/or expensive.

The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP).  The problem with this is that an ISP will likely have to run wire into your facilities to make those connections.  That can be disruptive as well as expensive and complicated due to locations within existing buildings.  And what if each business wants their own ISP because of a contract relationship?  That will mean multiple ISPs tearing up your facilities.  Not necessarily the best situation.

The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties.  I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth.  However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.

But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.

What Do You Do? Option 2 – Reduce Scope

There are also a couple of ways to reduce scope.  But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.

The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet.  However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.

Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization.  While this seems simple, it usually never is simple.  Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope.  Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections.  Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic.  It ends up more trouble than it is worth.

The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties.  That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.

Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity.  Those just complicate your compliance and reporting efforts.  All I can say is, if you can stop offering those services, stop.  If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services.  That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.

Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.

There you have it on third parties and their payments on your network.

Advertisement

Will The Council Kill Off TLS?

On February 6, 2019, a technical paper was published regarding a new attack on TLS 1.2 and 1.3 had been identified.  Of course, the first thing that a lot of us wondered was, “Will the PCI SSC now kill off TLS 1.2 and 1.3?”

Before panic sets in, I am guessing that TLS 1.2/1.3 will not go away like SSL v3 and TLS 1.0/1.1 did before.  The reason is that this is just another variation of the Bleichenbacher attacks that seem to crop up every so often regarding SSL and TLS.  What is different about this attack is the new side-channel leak approach that was used.

The risk in this attack is best described from the researchers’ technical paper.

 “… even though  the  use  of  RSA  in  secure  connections  is  diminishing (only ≈6% of TLS connections  currently  use  RSA  [1,  51]), this  fraction  is  still  too  high  to  allow  vendors  to  drop  this mode.  Yet,  as  we  show  in  Section  VI,  supporting  this  small fraction of users puts everyone at risk, as it allows the attacker to perform a downgrade attack by specifying RSA as the only public key algorithm supported by the server.”

The problem is all related to the use of RSA PKCS#1 v1.5 in TLS.  The rest of protocol is just fine.  So, at worst case I could see the Council recommending that RSA PKCS#1 v1.5 not be allowed to be used.

Which reminds me of years ago when the US banking regulators came out and stated that by a certain date, Internet Explorer 6 would no longer be allowed to be used for internet banking.  According to the banks at the time, such a move by the regulators would create a support nightmare or, even worse, kill off internet banking.  However, the date came, the banks turned off IE6 and little happened.  Yes, there were a few days of higher than normal support calls about customers not being able to get into their accounts, but those quickly died off.

The issue with RSA PKCS#1 v1.5 is similar to the banking story.  At what point do we draw the line on these sorts problems?  10% of users?  2% of users?  1% of users?  In this case, 6% of the internet users are putting the remaining 94% at risk.  Is it worth it?  Each organization will have to determine if that risk is acceptable and justify why.

Email And PCI Compliance

This is a question we got from the recent PCI Dream Team session.

“If you receive emails with CHD and store them for a defined period — does the exchange infrastructure come in to scope? What are the suggested methods to descope apart from not receiving CHD via emails.”

By definition, if an application processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD), it is in scope for PCI compliance.  The ONLY way to remove an application from PCI scope is to NOT process, store or transmit SAD/CHD.  So that should answer the questions presented.

With the question answered, I have written about email before, but I thought I would provide some additional guidance now that a lot of organizations are outsourcing their electronic mail (email) to providers such as Microsoft, Google and others.

Outsourcing email has become all the rage of late because it takes dealing with email off of IT’s plate.  IT people hate email because it is a huge operational pain with all of the problems it creates.  Not only does it typically take a lot of servers to operate, most organizations need a hot failover solution in order to ensure their business operations uninterrupted.  Never minding the fact that it is a problematic application that end users seem to often mess up.  Because of this, most IT operations look to a third party to deal with email and get it off their backs.

Over the years I have heard all of the business arguments as to why organizations need to use email for communications, particularly payments.  The most common of which is that it makes for easy communication with customers because everyone knows how to use it.  Add in file transfer, electronic facsimile delivery, voice messaging, unified communications and its ease of use – it is just too good to not use.  Talk about a business case that appears to be beyond reproach.

Here are the problems with email when it comes to PCI compliance.

The first problem, and it is HUGE, is that there is no way for an organization to obtain PCI scope reduction with email in scope.  By definition, an email solution that contains SAD/CHD, it is in the cardholder data environment (CDE).  You want everything in scope?  Well you got it because any workstation that uses email is at a minimum a “Connected To” system and at worst a CDE system if the end user processes the messages that contain SAD/CHD.  The bottom line is that your organization will not achieve any sort of meaningful scope reduction with email in scope because it brings every workstation in the organization into scope.

The second problem with email in scope is that it provides no real way of securing the information stored in the system.  Yes, inboxes can be individually encrypted, but it is trivial to work around that encryption and gain access to the messages, particularly if it is a shared or group inbox.  As a result, there is no way to effectively comply with the requirements in 3 regarding the encryption of CHD at rest.

Never mind the fact that you have to do something about redacting SAD if that is in messages.  That is because once a transaction is conducted, you are no longer allowed to store SAD.  Information redaction becomes hugely problematic in email systems because of where the data could have been sent unbeknownst to the original recipient as well as what email clients it exists.  This whole situation gets significantly worse if your organization must also comply with the European Union’s General Data Protection Regulation (GDPR).

The third problem is with requirement 4.2 that states:

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).”

This means that ALL EMAIL MUST BE encrypted at all times including internal and external message transmissions.  While this is easily accomplished for internal users, it becomes problematic for external users that will have to either use: (1) PGP or a similar public key infraustructure (PKI) solution, or use (2) a solution provided by your organization such as Proofpoint or similar to ensure secure message delivery.  I can personally attest to the fact that when I have brought up using PGP, Proofpoint or similar for secure communications, I have heard nothing but complaints from users about how difficult it is to use.  All of a sudden, ease of use goes out of the window.

But outsourced email is the final nail in the coffin for PCI compliance.  When you outsource your email to Microsoft, Google or other public cloud providers, they will tell you that their email solutions are NOT PCI compliant and NEVER WILL BE PCI compliant.  Worse, they will not allow you to assess their email hosting environment for your own PCI assessment.  As a result, there is no way to comply with requirements in 12.8 as well as comply with the card brand requirements of only working with PCI compliant service providers.  Therefore, there is no way to obtain a compliant PCI Report On Compliance (ROC) or self-assessment questionnaire (SAQ).

But what about compensating controls?

Any effort to create compensating controls is a giant bottomless rabbit hole.  You will chase your tail forever trying to come up with ways to compensate for controls that cannot be compensated.

In the end, while email is a great tool with excellent ease of use, it is a tool that will not easily lend itself to PCI compliance.  Only bring it into PCI scope if you absolutely have no other choice.  Othwise, avoid having it in scope like the plague.

One Last Time On Disaster Recovery

I have written three posts on this topic, yet it still comes up.

• Disaster Recovery Sites and PCI
• Disaster Recovery and PCI
• Business Continuity and PCI

Here are the Cliff Notes from those posts.

Hot sites are always in scope for PCI compliance because they can support failover on demand.

Cold sites are never in scope for PCI compliance because there is nothing there that would be in scope.

Warm sites are only in scope if they have cardholder data (CHD) processed, stored or transmitted from that site.

There are nuances with all of this, so if you want more information, read the three posts.

Open Source

One of the questions we received at the last PCI Dream Team session was:

“What about open source for 6.5?”

I am sure the person asking wanted to know whether open source payment solutions must comply with the PCI DSS requirements in 6.5.x?

The quick and simple answer is of course, ‘Yes’!  Why would it not?  It is source code after all, so therefore it must comply with the requirements in 6.5.x (as well as other requirements in section 6 and throughout the PCI DSS).  The PCI DSS does differentiate between different sources of application code.  For PCI compliance purposes, code is code is code, regardless of the source.

Now what does come into play is whether or not the PA-DSS validation standard applies to an application.  As PA-DSS relates to open source, I wrote about that over eight years ago, but it is still relevant today.  For the purposes of this post, I am not talking about PA-DSS validated applications.

The next question a QSA typically gets is, “Well 6.5 only applies to internet-facing payment applications, right?”

Wrong!  Any payment application needs to meet the requirements in 6.5.x whether it is internet-facing or internal facing.  Also, it does not matter whether a browser is involved or not although a significant number of the requirements in 6.5.x are related to browser-based applications.

But ensuring open source is PCI compliant goes beyond just 6.5.x.  There are other requirements that, at a minimum, must be applied as well.  Not every requirement in a section or group or requirements may apply, but some will be needed to be covered depending on how the application works.

• Section 3 related to encryption of stored data and encryption key management;
• Section 4 related to encryption of communications;
• Requirements 6.1 and 6.2 for patching and vulnerability management. This can become problematic for open source because as time goes on applications can develop vulnerabilities that the developer community does not address.  This is most likely because the community moved on and your application became an orphan;
• Requirements 6.4 for application development. Remember, just because your organization did not develop the application, if it is not PA-DSS validated, then it is your responsibility to ensure the code securely processes, stores or transmits sensitive authentication data and/or cardholder data;
• Requirement 6.6 is also in play regardless of whether or not the application is browser-based. At a minimum, code reviews must be performed.  If the application is browser-based, then you can add in a Web application firewall (WAF) for additional security;
• Sections 7 and 8 related to access control and user management; and
• Section10 related to application log data.

Remember, every time a new release of your open source solution becomes available, you have to go through all of this all over again if you intend to use the new release.

So those of you thinking that you can somehow leverage open source to reduce your PCI compliance footprint, think again.  All you have done is outsourced the development of your solution.  The rest is still on you.  In the end, it is really not much of a savings.

Pre-Authorization And Post-Authorization (Part 1)

Welcome to a new year.  I have had a number of interactions with a variety of people over the previous year and it has become obvious that the concepts of pre-authorization and post-authorization data is not clear to a lot of people.  These two concepts are a key part of understanding PCI compliance.  I will start with pre-authorization in this post and have a separate post for a discussion of post-authorization.

Pre-Authorization

Where pre-authorization (aka “pre-auth”) typically comes up is when someone asks, “How does [pick your online merchant] store a customer’s payment data and still be PCI compliant?”

Before we get to that question, we need to define what we mean by “pre-authorization”.  Pre-authorization is that time when a merchant has a customer’s sensitive authentication data (SAD) or cardholder data (CHD) but has not yet processed it for payment.

For most merchants, that time between collecting the SAD/CHD and processing it is measured in seconds.  For card present (CP) transactions, the SAD can be in the form of chip or magnetic stripe data.  For card not present (CNP) transactions, it typically includes the cardholder name, primary account number (PAN), expiration data and CVV/CVC/CID.  Regardless of transaction type, the data is sent off to either be approved or declined in seconds.

However, there are situations where that does not always happen that quickly.  Mail order telephone order (MOTO) and facsimile orders are the most obvious examples that can extend the amount of time between receipt of the CHD and processing by minutes, hours or even days and weeks.

But there are some not necessarily obvious situations where processing delays occur.

My first example of delay is when you go to fill your car with fuel.  When you swipe your card to pump the fuel, the system that manages the payment process will pre-authorize the purchase and then temporarily store the SAD until you finish pumping and hang up the hose to complete the transaction.  When you complete the transaction at the pump, the system sends through the actual charge and securely deletes your SAD from the system.  Depending on the size of your vehicle’s fuel tank and how close to empty you were, the system could have your SAD for quite a few minutes.

Another example is for the hospitality industry.  In the hospitality industry, a reservation typically does not cause a charge until a customer checks out even though they are required to have a card on file to hold the reservation.  When a customer checks into the property, the hotel’s billing system records the SAD and may also pre-authorize charges, but the actual card transaction is not processed until the customer checks out.  As a result, hotels can have SAD on file for the length of a traveler’s stay.  In fact, I have encountered SAD in hospitality systems that have been stored for more than a year due to reservations for special occasions such as graduations, birthdays, family reunions and anniversaries.

But getting back to the original question, the example that usually draws the most questions is in regards to when you, as a customer, store your card information with a merchant for future purchases.  These entities store your payment information (pre-authorization) in their applications so that you or they can quickly pay for your purchases without constantly re-entering your payment information.  These applications are not always part of a payment application, so they may or may not be PA-DSS validated.  However, when encountering them, I use the PA-DSS standard to ensure they process, store and transmit the SAD/CHD securely.  In addition, as a customer, you should have explicitly approved of the merchant storing your payment data and know how they will use that data.

Last, but not least, another great example of pre-authorization data are eWallet applications such as Google Pay and Apple Pay.  eWallets are just an electronic version of a consumer’s physical wallet.  eWallets are not regulated by the PCI standards or the card brands nor are they required to be PA-DSS validated.  Not that these eWallet applications are not secure, it is just that there is no one independently validating that they are secure.  That said, I always instruct developers of eWallet applications (or any pre-authorization applications) to follow the PA-DSS for developing a secure eWallet application.

The most confusion I encounter over pre-authorization data typically occurs regarding SAD/CHD that an organization receives via email or instant messaging.  A lot of QSAs get their undies in a bunch over when this happens and point to requirement 4.2 as the reason why this is unacceptable.  As a refresher, requirement 4.2 states:

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”

The operative word in 4.2 is “send”.  Requirement 4.2 says nothing about receiving PANs by these methods.  That does not mean that the Council recommends receiving PANs via email, IM or similar methods.  It is only recognition of what goes on in the real world.  There will always be a small percentage of people that will send their cardholder data insecurely and there is little an organization can do to stop it.

Yes, you can put a data loss prevention (DLP) solution in the middle of all of these messaging technologies and catch the bulk of the offenders.  But then what?

I have some clients who have taken this approach and the DLP securely deletes the message and triggers a message back to the sender stating that they do not accept payment card information via this communication channel and then explains all of the appropriate and approved ways a customer can communicate SAD/CHD.

I have other clients that use the DLP but do not delete the message.  They explain that in this one instance, they will process the transaction because they are all about the customer experience.  They have a process that they follow to handle the message and then securely delete it.

To keep your email, IM and other messaging systems out of scope, the Council has told QSAs that organizations must have a policy in place that says they never encourage customers to use these messaging channels for communicating SAD/CHD and to make sure that organizations have a process to remove the SAD/CHD as soon as possible from those systems.  That typically involves the printing of the message, deleting the message from the system(s) and then securely destroying the printed message once the transaction is processed.  This is all considered “incidental contact” in the eyes of the Council and the QSA can then consider the system out of scope as long as they can satisfy themselves that the manual process is reliable.

The bottom line is that all of these situations involve pre-authorization data and pre-authorization data can include everything recorded on a card’s track or chip.  If a merchant does store the pre-authorization data for the convenience of their customers, they are obligated under the PCI DSS to store it separately, away from post-authorization data and to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc. 

That is a key point that is often missed.  Pre-authorization data must be stored separately and away from any storage of post-authorization data.  That means that separate instances of databases need to be used on separate servers.  The rationale for this is no different than keeping key encrypting keys (KEK) away from data encrypting keys (DEK).  It is to ensure that in the event of a breach of post-authorization data, it does not readily lead to a breach of pre-authorization data.  It also allows for more rigorous controls over the pre-authorization data.

One final point regarding pre-authorization data that I made earlier, but it needs to be reiterated.  If a merchant intends to store pre-authorization data, I highly recommend that you have a legal agreement in place between your organization and your customers that explains why your organization is retaining this information and the business purpose(s) for which the information will be used.  That can be similar to a license agreement that the user either signs or clicks “Okay” online to acknowledge their approval.

In a future post I will discuss the world of post-authorization where the PCI standards were originally focused.

Why Voice Over IP Matters

“Voice over IP are the most insidious set of communication protocols ever invented by man.” – Jeff Hall

I have been having some interesting conversations of late with prospects and clients regarding Voice over IP (VoIP).  These conversations all seem to revolve around whether or not VoIP is in scope for PCI compliance.  Ultimately the conversation turns to a discussion of why I believe VoIP is in scope for PCI and almost every other QSA seems to never bring the subject up.

The primary reason I believe VoIP is in scope is that the PCI SSC says so.  If you read FAQ #1153 titled ‘Is VoIP in scope for PCI DSS?’ the Council makes it painfully clear that VoIP is definitely in scope if VoIP transmits sensitive authentication (SAD) or cardholder data (CHD).  If you doubt it, here is the exact quote from the first paragraph of that FAQ.

“While PCI DSS does not explicitly reference the use of VoIP, VoIP traffic that contains cardholder data is in scope for applicable PCI DSS controls, in the same way that other IP network traffic containing cardholder data would be.”

Yet even when it is stated that clearly, I still run into people that claim I am making a mountain out of a mole hill and their VoIP is not a risk because other QSAs have never inquired about it.  What that merely means is that other QSAs are ignoring it when they should not be ignoring it.

The first problem with VoIP seems to be that very few people understand it which is the biggest reason in my opinion that a lot of QSAs avoid the discussion.  But it is not just QSAs.  I speak with network administrators, information security personnel and other technology people all of the time and if there is one topic that will glaze over all of their eyes, it is VoIP.  When the discussion turns to VoIP, people seem to hark back to that old PBX system tucked away in the basement or closet.  No one seems to remember that the PBX did get updates (usually two or three a year).  All anyone remembers is that it just worked and that it got replaced once, maybe twice, in a generation.  And the biggest risk was toll fraud from the Caribbean.

But scarier yet is that these people do not seem to completely understand how VoIP and its protocols work let alone the risks.  The biggest problem with VoIP are the protocols used and the reason for my quote at the start of this post.  Regardless of whether you are talking SIP, H.323, H.248, whatever, they all operate the same.  Call set up (start of a call) and call tear down (end of a call) are the only points of a VoIP telephone conversation that are stateful, i.e., conducted via TCP.  The actual call itself is all done via streaming UDP just like any other audio/video stream.  Adding insult to injury, VoIP also requires a large number of the ephemeral UDP ports above 32767 to be open.  UDP, being what it is, provides one of the best transport mechanisms for delivering malware.  There are hundreds of exploits for VoIP from the most benign DDoS attack to turning a VoIP telephone into a spying device by surreptitiously enabling its microphone and video camera (if it has a camera).  But my personal favorites are the attacks that use the VoIP network as an entry point into an organization’s data network.  The bottom line is that the only way to firewall any of the VoIP protocols for actual protection is to keep them away from the rest of your network.

But it can and does get worse.  Add in VoIP trunks from your telephone carrier and you really begin to have a recipe for disaster.  When you have VoIP trunks from your carrier, your internal VoIP network is really only protected from every other VoIP network by the carrier and your call managers.  It is that sad fact that keeps a lot of information security professionals up at night.  If security is all about your weakest link, how do you protect yourself and minimize your risk when your weakest link is essentially the entire world’s phone systems?

Let us add insult to injury in this tale of woe and bring in the concept of unified communications and its primary tool, the softphone.  A softphone is software that turns a PC into a telephone using VoIP. All users need is the internet and a VPN connection to the office network and they have their office telephone right there no matter where they are in the world.  However, the softphone opens up that PC to the same risks that exist for every other phone using that call manager.  But if your VoIP system is used to take calls that discuss cardholder data (CHD), you have now turned that PC with a smartphone into a Category 1, in-scope device because it is now connected to a Category 1, in-scope system and network.  Suddenly all of that effort to achieve PCI scope reduction flies right out of the window.

But this all gets the more fascinating as people go back to their VoIP vendors and find out even more troubling issues with their VoIP solutions.  I remember numerous conversations where people thought once a call was connected to a phone that a call manager was no longer involved therefore the call managers could be put on a different network segment, only to find out that call managers act as bridges when calls are conferenced, involve telepresence or they are to/from outside lines.  They also find out that with the advent of unified communications, services such as instant messaging and email integration are no longer separate servers/functions from the call manager and cannot be easily segmented from the call managers to take them out of scope.

But then there is the revised draft version of the VoIP information supplement from the PCI SSC.  Great guidance if you have a call center.  Worthless for any other sort of implementation of VoIP.  It treats VoIP as a discrete operation as though only the call center model exists for VoIP implementations.  Granted call centers are the largest risk when they are in scope because their call volume is typically 80%+ of calls involving payments.  But all sorts of organizations take payment information over the phone but are not a call center model.

So, what about the organization that has call centers and also normal business people all on the same system?  Based on the information supplement, every phone is a Category 1 device unless the call center VoIP system is separate from the rest of the organization.

Must the call center be on a separate VoIP system from the other users?  It would appear to be that way to manage scope.  But again, there is no explicit guidance for any other implementation model other than a call center.

And if the other users take overflow calls from the call center or occasional calls dealing with PAN, how would separate systems help with that situation?  Near as I can tell, it does not help.

And what about unified communication solutions?  No idea as the information supplement does not reference a unified communication solutions.  However, given the whole premise of unified communications is that it is tightly integrated in most VoIP solutions, other communication methods such as instant messaging and telepresence would likely be in scope as well for PCI compliance.

The bottom line is that the advice I provided over six years ago in this blog is still accurate today.

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.

Just Because You Can Wait, Does Not Mean You Will Be Judged “Compliant”

Based on some of the questions I have received since my post on v3.2, apparently a lot of people missed this little point in my last post about the Council’s Webinar.

“The final key point on this topic that the Council could not stress enough was, just because the deadline has been pushed out was no justification for an organization to wait until the last minute before addressing these critical vulnerabilities.  If an organization can meet the June 30, 2016 deadline, then they should meet that deadline.  If they need until December 31, 2016 to convert, then they need to mitigate the risk until December 31, 2016 when they can drop SSL and early TLS.  But waiting for the sake of waiting because the deadline is in 2018 is unacceptable and needs to be called out as ‘Not In Place’ by QSAs.”

For all of you in denial out there, make sure you truly read that last sentence.

Yes folks.  Your QSA can mark you as non-compliant if your organization does not have a very, very, very good and legitimate documented business reason for not meeting the June 30, 2016 deadline for getting rid of SSL and early TLS.

Want to argue that point?  Fine.  Then you can expect your QSA to put you in arbitration with your acquiring bank on this subject.  If your acquiring bank is willing to sign off on your lame delay, then so be it.  But if your bank denies your request, then expect to be put into remediation by your bank and possibly even be fined for your arrogance.

And one more thing we have since clarified.  If you can meet the June 30, 2016 deadline, then you only need mitigation and migration plans for your QSA.  If you are not going to meet the 2016 deadline, then in addition to the plans your organization will also need to provide a compensating control worksheet (CCW) for 4.1.  Even if you are filing your Report On Compliance (ROC) before June 30, 2016, you still need to provide your QSA with the plans and the CCW if you will miss the 2016 deadline.

So for all of you out there that thought you had dodged a bullet, there is another bullet with your name on it.  You have been warned.

This Just In – SSL Conversion Deadline Has Changed

This is hot off the presses from the PCI SSC.

I’m not sure I necessarily like this decision, but I can appreciate what is driving it.  That said, I think the better approach would have been to have organizations do compensating controls for keeping SSL around.

Read the update for yourself.

http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls