Encrypted Cardholder Data – Out Of Scope?

I had an interesting exchange on Google+ the other day regarding whether or not encrypted data is in scope for PCI compliance.  In the end it was suggested that I write a blog entry regarding this topic as they said how to treat encryption has not been articulated very clearly by the PCI SSC.  I would argue that the rules regarding encryption and scope have been very clearly articulated in the PCI SSC’s FAQ #1086.  However, based on the conversation we had, it was obvious that this is not the case.  So here are the rules as practiced by most QSAs.

The key to how to interpret whether or not encrypted cardholder data is in-scope is in the FAQ.  Encrypted cardholder data (stored or transmitted) being out of scope is based on whether or not that data meets the following definition.

“It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.”

The important phrase in the aforementioned definition is “if, and only if.”  The only way encrypted cardholder data (CHD) is out of scope is if the entity being assessed for PCI compliance cannot decrypt the encrypted CHD.  This is a very important concept that gets constantly misinterpreted by QSAs and their clients.  However, it is up to the QSA to confirm that the organization being assessed cannot decrypt the encrypted CHD and to document the procedures conducted to prove that fact.

With that as background, let us look at storing and transmitting encrypted data and how they can be out of scope and what that means.  As you will see, out of scope can mean different things depending on the implementation of encryption.

Stored Cardholder Data

Under requirement 3.4, one of the methods recommended for the storing of the primary account number (PAN) is:

“Strong cryptography with associated key-management processes and procedures“

One of the ways organizations accomplish this is through a hardware security module (HSM) that manages the cryptographic key process.  The HSM generates the keys, manages the keys and provides an application programming interface (API) for code to access the keys.  Since the HSM is a “black box” a lot of organizations point to that fact as the reason their encryption is out of scope.

There is an additional condition to the encryption out of scope definition that usually gets forgotten.  This is what allows for the scope of the cardholder data environment (CDE) to be reduced.

“Systems performing encryption and/or decryption of cardholder data, and any systems performing key management functions, are always in scope for PCI DSS. Scope reduction for encrypted data may only be considered when that data is isolated from these processes.”

As such, since the organization using the HSM technically has access to the cryptographic keys through the HSM’s APIs, the encryption is in-scope.

Where stored encrypted CHD is out of scope is when a third party controls the encryption keys.  This most often occurs with tokenization.  Under a tokenization scheme, the CHD is sent to a third party who then securely stores the CHD and returns a token that links the CHD at the third party to the token stored by the merchant.  If the merchant needs to make any subsequent charges to the account, the merchant sends the stored token to the third party and the third party substitutes the stored CHD for the token and the transaction is completed.  But since the merchant does not have access to the token creation process, the token is out of scope because it is no longer considered CHD.

Transmitted Cardholder Data

Secure transmission of CHD can be accomplished through a number of methods.  The most common of these methods is secure sockets layer (SSL) or transport layer security (TLS).  In either case, if the organization being assessed has one of the endpoints in the SSL/TLS encryption, then the SSL/TLS process is in scope.  This is obviously most common in the conduct of e-Commerce when the merchant’s Web site has an SSL/TLS certificate for securing the transmission of the CHD to pay for the customer’s purchases from the Web site.

However we are also seeing SSL/TLS used more and more as the encryption method of choice for point-to-point encryption (P2PE) solutions.  Again, if either of the endpoints in the P2PE environment are under the control of the organization being assessed, then the endpoint or endpoints are in-scope for the PCI assessment.

One way we do see to get everything but the merchant’s endpoint out of scope is terminals that are encrypted from the terminal to the processor and the processor controls the encryption keys for the P2PE.  This is most often used in the gas station environment where the pump card reader does P2PE to the processor using derived unique key per transaction (DUKPT) or similar techniques to create an encrypted connection.

That said, what happens to the users and devices in between the two encryption endpoints on an encrypted communication link?  They are out of scope as long as they do not have the ability to decrypt the data stream.  This is another misunderstood interpretation of the FAQ.  While some personnel inside an organization have access to encryption keys, if a user or device does not have access to the encryption keys or the communication endpoints, they too are out of scope.  This is how an SSL/TLS/IPsec connection can be used for isolating the transmission of CHD from the rest of the network and satisfy network segmentation.

Another issue that comes up with managed service providers (MSP) is when the MSP has access to firewalls or routers that are encryption endpoints.  Even if the MSP does not have access to the encryption keys, they do have access to the encryption endpoint(s) and cleartext CHD, therefore their personnel and relevant device management practices are in-scope for PCI compliance.

The bottom line in all of this is; if your organization has the ability to decrypt either the stored CHD or transmissions of CHD, then you are in-scope for PCI compliance.

And as a reminder to everyone, just because something is out of scope it does not mean that it does not need to be assessed.  It is always necessary for a certain amount of testing procedures to be conducted to determine that the item is out of scope.

Hopefully we can now all operate from the same set of rules.

Service Provider PCI Compliance Process

As a recent question pointed out to me, while service providers now seem to understand they need to be PCI compliant, they do not seem to understand the process under which they assess their PCI compliance.  As a result, I thought I would use this space to clarify this process.

When Do I Have To Be PCI Compliant?

The PCI SSC defines a Service Provider in the PCI DSS Glossary as:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data.  This also includes companies that provide services that control or could impact the security of cardholder data.  Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities.  Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.”

On the straight forward side of this definition, if your organization processes, stores or transmits cardholder data on behalf of one or more other organizations, your organization is considered a service provider and needs to be PCI compliant.  That point seems to be clear and most organizations that are processing cardholder data for others understand this fact.

It is organization that do not directly process, store or transmit cardholder data but could impact the security of cardholder data that get tripped up.  The bottom line is, any third party that has access to an organization’s cardholder data environment (CDE) needs to be PCI compliant for those services offered that come into contact with the CDE.

Based on this definition, the following are examples of services would need to be PCI compliant.  This is not a complete list but something to assist you in understanding why your organization might need to be PCI compliant.

• Management of firewalls that are considered part of an organization’s CDE.
• Management of networks that carry cardholder data that is not encrypted.
• Management of encrypted networks that carry cardholder data and the MSP manages the encryption keys for encrypting the network.
• Management of servers that process, store or transmit cardholder data.
• Management of PCs that have access to cardholder data.
• Management of applications that process, store or transmit cardholder data.

The first question service providers typically ask is, “How am I supposed to know if my customer needs our services to be PCI compliant?”  My rather indignant response is, “What, you cannot ask them?”

If you are a service provider and you are providing any value added services, you need to be asking every customer about their regulatory or legal requirements when going through the sales and contract processes.  It is not just PCI these days, but in the US there is HIPAA, GLBA, SOX and there all sorts of similar requirements in various parts of the world that you should be finding out whether your prospects need to comply.  If you are not, then you are sitting on a potential legal time bomb should something happen and your value add services are deemed the culprit.

SAQ D or ROC?

Service providers are broken into two levels, Level 1 service providers and Level 2 service providers.  Level 1 service providers are those that process more than 300,000 Visa, MasterCard or Discover transactions annually and are required to perform a full PCI assessment using a qualified security assessor (QSA) that results in a Report On Compliance (ROC).  Level 2 service providers are those that process 300,000 annual transactions or less and they can conduct their own assessment using the SAQ D.  SAQ D is the only SAQ that service providers are allowed to use.

The first issue most MSPs face is determining what parts of the ROC or SAQ are relevant.  There are no easy answers in this area as it all comes down to those value added services you are providing and how you provide those services.  However, before you can determine what parts of the ROC or SAQ are relevant, you need to determine the services that are to be assessed.

Where MSPs can miss the boat is taking the lowest common denominator approach and only assessing those value added services that all customers need to be PCI compliant.  Typically this results in an AOC that discusses physical security (requirement 9) and security policies (requirement 12).  If you take the lowest common denominator approach, then do not complain when each of your customers’ QSA have to traipse through your facilities and disrupt operations over the value added services you did not cover in your AOC.

The best approach is to assess all value added services you provide so that you do not have to worry about whether or not a given service is PCI compliant.  The reason this is important is that customers are required to make sure that all service providers that need to be PCI compliant are PCI compliant.  It is not that customers cannot work with non-PCI compliant service providers; it is just a lot easier to work with PCI compliant service providers.  The reason is that non-PCI compliant service providers have to be annually assessed as part of the customer’s PCI assessment as well as the customer is supposed to be monitoring the service provider’s PCI compliant efforts.  As a result, you will have an easier time and be easier to deal with if all of your value added services are PCI compliant.

Now back to what parts of the PCI DSS are relevant.  There are too many permutations of services and PCI requirements to go into this for every possible situation, so I am just going to provide some examples.

If you are providing firewall management services, then you are going to have to comply with requirements 1, 2, 4 (if your organization is managing any transport encryption), 5 (the PCs/servers used to manage the firewalls), 6 (change control for the PCs, servers and firewalls), 7, 8, 9, 10 (log management and analysis for the PCs, servers and firewalls), 11 (PCs, servers and firewalls) and 12.  Some tests in these sections may be Not Applicable for your organization, but you will need to go through all of the tests in the sections.

If you are managing applications such as in a software as a service (SaaS) environment, you are going to have to comply with requirements 1 (if you manage any firewalls or routers that could be in-scope), 2 (servers, firewalls, routers, switches), 3 (if your application encrypts the cardholder data), 4 (if your network encrypts cardholder data), 5 (servers running the application as well as any support PCs and servers), 6 (change management as well as any software development), 7, 8, 9, 10, 11 and 12.  Some tests in these sections may be Not Applicable for your organization, but you will need to go through all of the tests in the sections.

As you can see, even a “minor” service such as managing firewalls can require a significant amount of effort to be PCI compliant.

Do I Need A QSA?

A Qualified Security Assessor (QSA) is only required if: (1) your organization is considered a Level 1 service provider, or (2) you wish to have your organization listed on Visa’s Global Registry of Service Providers or with the MasterCard Registration Program (MRP).  In both of these cases, you will need to hire a QSA and produce a Report On Compliance (ROC) and Attestation Of Compliance (AOC).  If you can answer ‘No’ to both of these, then you can do your own assessment using the SAQ D.

Scope Of Assessment

At the 2012 PCI Community Meetings, the PCI SSC clarified scoping for PCI assessments.  The PCI SSC stated that:

“To be considered entirely out of scope, a network or system must be isolated from, with no connectivity into, the CDE (such that even if the system is “owned”, it cannot impact the security of the CDE).
If connections are limited to specific ports or services, those systems are included in PCI DSS scope to verify applicable controls are in place.
Applicable PCI DSS controls may vary for in-scope systems depending on the function of the system and presence of other controls.”

As a result, any of your systems that have access into a customer’s CDE are in-scope for compliance as they could be used to access the CDE.  This does not mean that these systems need to meet all of the requirements of the PCI DSS.  But it does mean that they need to be evaluated to determine those portions of the PCI DSS that do apply.  All of this is dependent on the potential to access cardholder data inside the CDE.

To minimize the impact of this clarification, we are seeing a lot of MSPs using “jump boxes,” PCs that do nothing but provide access into the systems to be monitored or managed.  This provides an air gap between the MSPs internal systems and the customer’s environment, including the CDE.  As a result, the jump boxes need to be PCI compliant and the internal systems at the MSP just need to have current anti-virus and anti-malware and be properly authenticated.

Hopefully this post helps all of you managed service providers that are facing PCI compliance.

This post was revised after a review by Walt Conway at 403Labs pointed out some inaccuracies.  A big thank you to Walt for his diligent eye.

Bring Your Own Device And PCI Compliance

Bring your own device or BYOD is all the latest rage.  I believe that the reason for that exuberance is the consumerization of technology.  It is that exuberance through BYOD that has made everyone an “IT expert.”  Just ask any user of a smartphone or tablet and they will baffle you with vendor lingo regarding BYOD.  However, regardless of what these people think, there is a big difference from consumer use and enterprise use, the first of which is security.  In this post I am going to look at the minimum PCI DSS requirements BYOD will have to comply in order for your organization to maintain PCI compliance.

From a PCI perspective, requirement 12.3 is very relevant in the BYOD discussion.

“Develop usage policies for critical technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), e-mail usage and Internet usage) and define proper use of these technologies. “

Under 12.3, there are eight sub-requirements that require:

• Explicit approval by authorized parties.  Just because you have a smartphone or tablet, does not imply you get an automatic pass to connect, you must be approved for that privilege.  In most organizations, that means you need to provide a business need to have such a privilege granted.  While access to email through a smartphone or tablet is one thing, access to cardholder data should be another and be granted very judiciously, if at all.
• Authentication for use of the technology.  If you think you are using a PIN, think again.  You still have to log onto any PCI in-scope system using a password that meets the PCI DSS requirements.  By the way, two-factor authentication is required to access cardholder data remotely, so BYOD does not get you a pass there either.
• A list of all such devices and personnel with access.  For organizations issuing BYOD, this is not a problem.  For organizations allowing any Apple iOS, Android or Windows device to connect is problematic.  While it can be done, you will need to document who was granted access, for what reason/purpose, and what they are using to obtain that access (i.e., make, model, etc.) even if your organization is not providing the devices.
• Labeling of devices to determine owner, contact information and purpose.   I take issue with identifying purpose of the device as that, in my opinion, could just make someone ever more curious as to what is on the device.  However, identifying the owner, giving their general business address and general voice and facsimile telephone numbers for their location is what I would recommend.
• Acceptable uses of the technology.   Email is one thing, doing something that involves cardholder data is another.  I think if companies think this through, there is probably little, if any, reason for BYOD to be even near the cardholder data environment (CDE).  However, if for some bizarre reason you can come up with a valid reason, then all requirements for remote access of cardholder data apply such as personal firewall, no way to disable the firewall, strong passwords, two-factor authentication, encrypted connection, etc.  And remember that these devices have keyboard loggers, so all data input is recorded so keep that fact in mind when designing your information security requirements for BYOD.
• Acceptable network locations for the technologies.  In the case of BYOD, this is anywhere outside of the organization’s network perimeter.
• List of company-approved products.  For those organizations issuing the BYOD, this is not a problem.  For those of you that allow anyone with anything to connect as long as it runs iOS, Android or Windows 8 RT/Pro, your list is going to say “Any iOS, Android or Windows 8 RT/Pro device.”
• Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.  With BYOD, this can be problematic as most BYOD do not use traditional remote access connectivity and inactivity can all be in the eye of the beholder, so to speak.  As a result, inactivity timeouts can be difficult, if not impossible, to enforce in some instances.  As a result, you may have to be either creative or use a compensating control to comply with this requirement.

Going through the above, I think most organizations would see BYOD for what it is – a fad.  Do not get me wrong, BYOD has its uses in the corporate environment, but they are fairly limited and likely does not include cardholder data.

However, if you have come up with a business justification for processing, storing or transmitting cardholder data using BYOD, there are number of other requirements you are going to have to address.  I know there are other potential requirements that could be involved, but these are the most well known that will need to be complied with under the PCI DSS.

• Requirement 1.4 – Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.   While this can be accomplished by a number of security vendors, it is the enterprise management of those solutions that is currently lacking and the ability to globally enforce policies.
• Requirement 3.4 – Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs).  Most cell phones and tablets do not support device encryption.  As a result, how will you protect any cardholder information stored on the device?  Remember that these devices have keyboard loggers, so any cardholder data input on the device is collected and stored by the device whether you like it or not.  The bottom line is that you will have to restrict BYOD to only those devices that can support whole device encryption.
• Requirement 4.1 – Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.  You would not think that this would be a significant problem, but it can turn out to be very significant and I will speak about this later on.
• Requirement 8.3 – Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.  This capability is available, but if you are using any of the solutions that run on the BYOD, your users will likely have issues trying to connect and get their token value from that device.
• Requirement 8.5.10 – Require a minimum password length of at least seven characters.  This is likely a deal breaker for users.  Most like their PIN or swipe and will not want to give them up for a seven character, strong password.  In addition, some security solutions may create a situation where the phone cannot be answered without unlocking the device and, a seven character password may cause calls to be missed.
• Requirement 8.5.11 – Use passwords containing both numeric and alphabetic characters.  This can be problematic when some virtual keyboards require flipping between three or more screens to get to certain special characters.  With phones with physical keyboards, there may be limitations to the number of special characters available that could create problems with the password uniqueness requirement in 8.5.12.
• Requirement 8.5.13 – Limit repeated access attempts by locking out the user ID after not more than six attempts.  Some security systems may not be able to enforce this without wiping the device.
• Requirement 8.5.14 – Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.  I am not aware of a security solution currently available that can enforce this on a smartphone or tablet.  You will have to meet this with a compensating control.
• Requirement 8.5.15 – If a session has been idle for more than 15 minutes; require the user to re-authenticate to re-activate the terminal or session.  As with 8.5.14, I am not aware of a security solution that can enforce this on a smartphone or tablet.  You will have to meet this with a compensating control.
• Requirement 10.2 – Implement automated audit trails for all system components to reconstruct events.  This is not an issue with Android and may be an issue with Windows 8 RT, but is definitely an issue with Apple iOS.  There is no utility I am aware, outside of forensic utilities, which can meet this requirement in an Apple iOS environment.  In addition, I am not certain how you get this log data back for any sort of analysis without chewing up a tremendous amount of data bandwidth or device memory.  At the end of the day, this will also likely be satisfied by a compensating control, if you can actually come up with enough controls that go above and beyond the PCI requirements.
• Requirement 10.3 – Record audit trail entries for all system components for each event.  If meeting requirement 10.2 is a gymnastic event, then there is the configuration of the log data to ensure that all of the necessary log information is collected.  I am sure that under Android and Windows there is probably some way to ensure that the necessary log data is required.  But with Apple, iOS, Apple will have to be able to provide this capability.  And knowing how stubborn Apple can be about having their hand forced in these matters, getting access to configuration of log data let alone log data will likely be a battle.  Again this will also likely be satisfied by a compensating control, if you can actually come up with enough controls that go above and beyond the PCI requirements.
• Requirement 10.4 – Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.  For smartphones, they get their time synchronization from the carrier.  However, that time does not likely correlate to the time used by enterprise systems.  It will be close, but not necessarily the same thus complicating any forensic examination if one is required.  This can obviously dealt with in a compensating control.
• Requirement 10.5 – Secure audit trails so they cannot be altered.  Given that users have administrator access on their BYOD; this could be a problem that cannot be easily solved.  Yes, there are security solutions available that can lock down a device, but they can also lock them down so far that users can begin to wonder what the point of having the device is.  As a result, you will find you have a very fine line to tread in this area.

In the end, you start to understand why BYOD is a difficult thing to justify when you need to comply with all of the aforementioned PCI requirements.  But there are a few other considerations that you will still need to address.

The first situation that should concern any organization considering BYOD is the loss of that BYOD.  It is virtually guaranteed that BYOD will result in lost devices and you will need policies, standards and procedures to address that eventuality.  The way most organizations address this issue is providing a remote device wipe capability that can be invoked whenever a device is reported lost.  Not that such capability ensures that every lost device is wiped, but it is better than nothing, but not by much.  This is usually backed up by the bad password entry policy that wipes the device after six incorrectly entered passwords.  So even if the remote wipe does not destroy the data, the bad logon attempts will.

BYOD brings up an information ownership issue as, according to the latest statistics, 70% of all BYOD are owned by the employee, not the organization.  As a result, you are allowing the organization’s information to be processed or stored on a device not owned or necessarily even controlled by the organization.  While you can have an employee sign an agreement regarding the organization’s ownership of the information and the employee’s responsibilities for protecting that information, the issue of enforcement of such an agreement can be very problematic depending on platforms and other technology issues.  You can have a remote wipe capability, but that brings up the potential legal issue of can you also wipe an employee’s personal information such as contacts, music and pictures as well?  Just remember the old saying, “Possession is nine tenths of the law.”  When you finally get through court proceedings, does it really matter if you won when the data has already likely been disseminated?

Then there is the question about whether your applications actually capable of dealing with BYOD?  Most internally facing applications that employees desire access are not engineered for secure, remote access from BYOD.  As a result, a lot of organizations are turning to VPN technology to solve the remote access issue.  However, organizations using VPN are finding out that, while VPN clients are free for download to the BYOD, licensing for the BYOD VPN client is over and above the licensing the organization has already purchased for notebooks.  In addition, depending on the device, running the VPN client can make devices run very slow to the point of being worthless when connected.

When VPN is not a solution a lot of organizations are using remote desktop (RDP), Citrix virtual desktop or similar remote control environments to provide secure access to internal applications.  Having worked with a few of these in a smartphone and tablet environment, I can tell you their use is haphazard at best due primarily to screen size and lack of a mouse and a real keyboard.  In addition, we also find that some of these secure remote desktop solutions are not using secure communication methods.

In addition to VPN and remote control, a lot of organizations are implementing HTTPS for secure connectivity to their applications.  However, this creates all sorts of new security issues related to authentication and protecting the applications which are typically not engineered to be externally facing.  We are finding that in the rush to enable applications for HTTPS, there are numerous security vulnerabilities that are being introduced.  We also see vulnerabilities as well with applications developed specifically for mobile devices.  In the haste to get BYOD up and running, the security vulnerabilities are not corrected before the applications are put into use (a violation of PCI DSS requirement 6.6) which puts the applications and, potentially, the internal networks at significant risk of compromise.

And finally, data input from smartphone and tablets can be highly erroneous not just because of human typing errors but also because of auto-correction systems that are implemented on these devices.  Anyone considering significant data entry through BYOD is just asking for trouble as this erroneous data input could result in legal issues later on due to mis-spellings and mistakes in addresses and other information.

Most executives do not understand the security and privacy issues of BYOD because they have not encountered them and are not aware of them even when time is taken to educate them.  Unfortunately it usually takes an executive losing their BYOD to help management appreciate the issues with BYOD and to slow down the drive to integrate BYOD until their concerns regarding security and privacy are addressed.

As you can see, using BYOD is not as simple a process as your end users might think.  This is even truer when that BYOD will be part of your cardholder data environment (CDE).  There are a number of innovative solutions for BYOD that are secure, but those solutions are expensive and make the BYOD only a display device.  However, if you want to be able to sleep at night, I would highly recommend looking at those purpose built solutions.

The Amazon Cloud And PCI Compliance

If there ever was a hot topic these days it would be “The Cloud” and, in particular, the Amazon cloud.  And that discussion inevitably leads to how are the Amazon cloud offerings are PCI compliant?  A lot of this discussion has to do with the very limited amount of information regarding the Amazon service offerings.  For some very bizarre reason, Amazon puts organizations interested in their PCI compliant services in a Catch-22 situation.  Unless you sign up for one or more of the services, you cannot obtain the information on how the Amazon service offerings are PCI compliant.  As a result, there is a lot of mis-information running around regarding the Amazon cloud.  So to debunk all of the myths running around, I thought I would explain what the Amazon cloud is and is not and how it ends up PCI compliant and what you need to understand when deciding to use the Amazon cloud.

And before I get calls from someone at AWS about the fact that I am somehow singling them out or I am being unfair.  I do not have a problem with AWs or anyone organizations’ cloud service offerings.  What I have an issue with is how some service providers use obfuscation and confusion about their services in ways that make customers unsure of whether they are getting something that is PCI compliant.  As I see it, the AWS service offerings seem to be PCI compliant, but there are things that possibly should be further explained so that everyone understands how that compliance is achieved.

The first part of the mythology revolves around what PCI compliant services Amazon Web Services, LLC (AWS) is actually providing.  According to AWS’s Attestation Of Compliance (AOC), AWS is a Hosting Provider for Web and Hardware.  The AOC calls out that the following services have been assessed PCI compliant.

• Amazon Elastic Compute Cloud (EC2);
• Amazon Virtual Private Cloud (VPC);
• Amazon Simple Storage Services (S3);
• Amazon Elastic Block Store (EBS);
• Amazon Relational Database Service (RDS);
• Amazon Elastic Load Balancing (ELB); and
• Amazon Identity and Access Management (IAM).

The AOC lists nothing for software provided through any of their services.  As a result, a big myth that gets busted right off the bat is that AWS is providing software.  At the end of the day, all AWS’s services are offering is Infrastructure as a Service (IaaS).  As a result, how AWS is PCI compliant is fairly easy to figure out.  They have totally minimized their responsibility on the PCI compliance front.

In addition to the AOC, AWS provides customers with a document entitled “AWS PCI DSS Controls Responsibility Summary” (CRS).  This document explains the various services and the responsibilities a customer organization has when using these services.

The first piece of infrastructure used by AWS is virtualization in the form of Xen as their hypervisor.  Because of the way AWS has implemented Xen, every virtual instances created by EC2 acts like an individual physical server in that there are no connections to any other server unless the organization defines such connections.  This is referred to in the CRS as instance isolation.  Finally comes the firewall.  EC2 includes a firewall that is managed by the customer.  Access to the firewall is controlled by an X.509 certification and access credentials provided through IAM.  In addition to utilities to manage the cloud environment, AWS provides various application programming interfaces (API) to manage the AWS cloud environment.

The bottom line is that, at a minimum, an organization needs to subscribe to EC2, VPC and S3 in order to build a basic platform capable of computing (i.e., server, connectivity and storage).  The need for other services outside of these will depend on what the organization is attempting to accomplish, whether or not they need the flexibility and scalability provided by AWS and other business factors.

From a PCI compliance perspective, the CRS categorizes the 12 PCI requirements into those that are AWS’s responsibility, shared responsibility between AWS and their customer and those requirements that are solely the customer’s responsibility.

In the AWS is responsible category falls requirement 9 or physical security and environment controls.  Since AWS is providing the facilities to operating the underlying physical hardware, it is solely responsible for this requirement.

In the shared responsibility category falls requirements 1, 10 and 11.  For requirement 1, AWS acknowledges that this is a shared compliance responsibility between AWS and their customer.  However, AWS’s responsibility is only to provide a firewall and ensure that it segregates their customers from one another.  The remainder of the responsibility for complying with requirement 1 is left to the customer.

For requirement 10, AWS indicates that they are responsible for:

• Maintaining log files for EC2 and S3 customer management operations (e.g. creation, modifications and deletion of these environments) for at least a year.
• Maintaining logs for the underlying software that provides the various services for at least a year.

This log information is monitored at least daily and is available to customers for their particular environment should it be necessary.  All other parts of requirement 10 are the responsibility of the customer.

For requirement 11, AWS indicates that they are responsible for ensuring the security of their environment including ensuring wireless security.  Customers are responsible for ensuring the security of the environments they construct using AWS’s services.

All of the remaining requirements, 2, 3, 4, 5, 6, 7, 8 and 12 are solely the responsibility of the customer.

So after all of this rigmarole, what is the advantage to be gained?  Not much near as I can tell.  The bulk of responsibility for PCI compliance still falls on the organization using the AWS services.  So organizations looking to offload as much of their PCI compliance responsibilities as they can to AWS are looking in the wrong place.

But it does not end there.  We are seeing more and more startup service providers that are using AWS services to avoid the capital costs of hardware and software of a 24/7/365 operation.  Where this becomes tricky is when you have a service provider providing PCI compliant services effectively using AWS for their “data center.”  In some cases, these service providers are trading on the fact that because AWS is PCI compliant, then their services must also be compliant.  However, what these service providers forget is that once they start going beyond the IaaS model and offer services in the Platform as a Service (PaaS) and Software as a Service (SaaS) realm, they are now responsible for portions of PCI compliant that Amazon is not.  As a result, organizations need to conduct due diligence on vendors using other cloud providers to provide their services to ensure that everyone is PCI compliant.

So do I think your organization should rush right out and sign up for AWS?  Maybe if you have the right business case.  But I do have some concerns regarding AWS’s service offerings and the statements surrounding how they are PCI compliant.

My first concern is in regards to requirement 1.2.3.  This requirement is one of the few that is not allowed to be marked ‘Not Applicable’.  As such, the QSA is required to document what procedures they conducted to ensure that any existing wireless is either not in-scope or that there is wireless in-scope and how it is secured.  To document this, AWS’s QSA has written:

“[AWS] maintain this control for all internal and external services that it provides. In EC2 and VPC environments, this includes the network at the hardware and management level networks, which are not exposed to customers.”

This statement says nothing of what procedures were conducted to ensure that wireless was not visible to customers as well as the controls AWS maintains to ensure wireless stays out of scope.  Essentially, we are asked to trust AWS that wireless is not on any customer networks.  Now, to be fair, AWS is operating secured data centers comprised with racks of hardware all virtualized, so the likelihood that wireless would exist in such an environment on any one customer’s network is remote at best. .  However, the PCI assessment process is all about verifying such statements, not just accepting them at face value as fact.  As a result, I am concerned that what is supplied as evidence for complying with this test leaves much to be desired.  What should be documented here are the procedures the QSA used to confirm that the controls AWS has in place are adequate to ensure that rogue wireless does not end up in their data centers.

Related to requirement 1.2.3 is requirement 11.1.  As with 1.2.3, 11.1 is also not allowed to be marked as ‘Not Applicable’ regardless of whether wireless is implemented or not.  For all of the tests under 11.1, the following statement is made.

“[AWS] maintain[s] this control internally.”

So what exactly does AWS do to ensure that their data centers remain wireless free or that wireless does not end up on the customer side of the network?  No idea.  I would like to assume that AWS is doing the right things in this regard, but, again, the PCI assessment process does not allow for assumptions, they require proof and this just does not pass muster.  At a minimum, there should be a discussion of the procedures used by AWS to ensure wireless is not an issue.

While we are discussing requirement 11, we should cover vulnerability scanning, penetration testing, intrusion detection and critical file monitoring.  All of which are the customer’s responsibility, not AWS’s.  Again, AWS is providing IaaS and nothing else, so any such controls will need to be provided by the customer.

When reviewing the detailed responses in requirement 9, it was interesting to see that AWS is responsible for ensuring that for the portion of any customer’s cardholder data environment (CDE) that exists in AWS, AWS ensures that destruction of hardcopy materials are properly destroyed so to be unrecoverable.  This begs the question, “Why would AWS have any hardcopy to destroy in the first place if they do not have access to customers’ environments?”  No further explanation is given, but one would guess it was their lawyer’s idea just in case AWS might somehow come into contact with CHD on hardcopy.

The next area I have issue with is not related to the service, but related to how an organization contracts for the service.  In an effort to fully automate things, unless you are a Fortune 50 looking to put your entire computing environment in AWS’s data centers, you can forget about negotiating a contract.  When you sign up for any AWS service, you either accept their contractual terms and conditions by checking the ‘Accept’ box and clicking Okay, or you don’t get to use AWS.  I know of a number of organizations that had real issues with that approach and, as a result, backed away from a more aggressive use of the AWS environment or decided they just could not accept the terms and did not go to the cloud at all.  While the AWS contract does cover PCI compliance, but it essentially makes the customer the one legally responsible for compliance with AWS providing support when necessary.

So that is AWS in a nutshell.  Not a bad thing, but something an organization needs to go into with their eyes wide open and understanding that they still have significant responsibilities even though they are now in “The Cloud.”

Third Party Service Providers And PCI Compliance

There seems to be a lot of confusion regarding third parties that provide networking or hosting services and their obligations regarding PCI compliance.  This confusion is not uncommon as merchants and their service providers have not necessarily been provided enough guidance to understand their obligations.  I hope this post will clarify those obligations for all involved.

If you learn nothing else from this post, if a third party is providing your organization a service that has access to your cardholder data environment (CDE) or the third party could come into contact with your cardholder data (CHD), then that third party must ensure that the service complies with all relevant PCI requirements.  As a result, the third party needs to either allow you or your QSA to assess the services that they are providing or provide you with an Attestation Of Compliance (AOC) that documents that those services have been assessed and they are PCI compliant.

In the past, I have stated that third parties could also submit a letter signed by an officer of the third party stating that all of the services provided to their customer are PCI compliant.  Now that v2.0 of the PCI DSS has a separate AOC and the PCI SAQs have the AOC built into the SAQ, there should be no reason to need such a letter or to ask for one.  If a letter is what your third party is offering, it is better than nothing, but you should be pushing them hard for an AOC.  If they are reluctant to get you an AOC, as part of your vendor management process, you should take that into account and probably begin looking for a new vendor that will provide an AOC for their services.

The most common issue we run into with third parties is that their AOC or other representations of PCI compliance do not cover all of the services provided to the customer.  In case after case, we see the AOC covering requirements 9 and 12 and nothing else even though the services provided may require compliance with some or all of PCI requirements 1, 2, 3, 4, 5, 6, 7, 8, 10 and 11.

In a lot of cases, it is not that the third party does not want to comply with PCI; it is they are taking the lowest common denominator approach and only picked those services where all customers requiring PCI compliance are asking for an AOC.  That way they have reduced their costs of a QSA to assess their environment.  These third parties are accepting the fact that any customer that needs more services assessed will have to do it themselves.

Related to this issue is the third party that offers their SSAE 16 Service Organization Control (SOC) 1 report has proof of PCI compliance.  While a SOC 1 report can cover a few PCI requirements, people must remember that the SOC 1 report is structured specifically for financial auditors to ensure that the controls at a third party are properly constructed to support financial reporting at the customers.  As a result, a SOC 1 report is not going to be a substitute for an AOC that covers all services.  There is an alternative to this and that is to have the third party go through a SSAE SOC 2 report that focuses on the security controls of the PCI in-scope services provided.  We are hearing from third parties inquiring into the SOC 2 report, but cost and a lack of customers requesting such a report are driving why we do not see more SOC 2 reports available.

Another common issue we encounter is the refusal of the third party to cooperate in assessing the services provided to ensure they are PCI compliant.  There are still third parties that argue their services are not in-scope for PCI compliance even when it is painfully obvious that the third party’s personnel have access to their customer’s CDE and/or CHD.

The most common third party relationship we encounter is the management of routers or other layer 3 devices.  Where we encounter the most confusion in this relationship is in regards to the use of encryption to keep the network services organization out of scope for PCI compliance.  The key here is if the network services organization manages the encryption of the network, then they are in-scope for PCI compliance.  The reason is that the employees of the network services organization have access to the encryption keys and therefore could decrypt the communications and gain access to CHD transmitted over the network.  As a result, at a minimum, the network services organization is responsible for complying with some or all of requirements 1, 2, 4, 6, 7, 8, 9, 10 and 12.  If you receive such services and are not getting an AOC that covers these requirements, then you should be doing more work on your own as well as asking the third party why they are not covering more of the necessary PCI requirements.

The next most common service we encounter is the network services firm that is managing or monitoring an organization’s firewalls, remote access or intrusion detection/prevention.  Such services always put the third party in-scope for PCI compliance.  Some or all of requirements 1, 2, 6, 7, 8, 9 and 12 will need to be assessed for compliance with the PCI DSS.  The log capture and analysis requirements in requirement 10 may also be complied with if your organization is not capturing and analyzing the log data from these devices.

Another group of third parties we encounter a lot are records retention vendors.  Organizations like Iron Mountain have conducted their own PCI compliance project and readily hand out their AOC to customers.  However, where we see issues is with such vendors that provide their own tape library for their customers to use for backup.  We have encountered a number of third party’s doing the encryption at their library which puts them in-scope for PCI compliance, at a minimum, for requirements 3, 4, 6, 7, 8, 9, 10, 11 and 12.

We encounter outsourcing the data center a lot with large organizations, but small and mid-sized organizations are also hopping on the data center outsourcing bandwagon.  Where this puts the third party in-scope for PCI compliance is when the third party is responsible for maintaining the environment such as applying patches, managing servers or any other activities that would allow the third party’s personnel to potentially have access to CHD.  In such situations, at a minimum, the third party is responsible for complying with some or all of requirements 2, 5, 6, 7, 8, 9, 10 and 12.  Compliance with some or all of requirement 1 may be applicable if the third party is managing your firewalls or routers.  Compliance with some or all of requirements 3 and 4 may also be applicable if the third party is responsible for managing encryption keys for encrypting CHD or encrypting communications.

Where the most confusion regarding third party responsibilities occurs is in regards to “The Cloud.”  The most common reason for this is that every vendor seems to have a different definition for what “The Cloud” is, based on their particular services.  Using the definitions provided by the National Institute of Standards and Technology (NIST) in their publication SP800-145, ‘The NIST Definition Of Cloud Computing’, I can provide the following guidance.

If your organization is purchasing Infrastructure as a Service (IaaS), then the third party providing these services will typically be out of scope for PCI compliance except for requirements 9 and 12.  There are some instances where IaaS implementations may require compliance with the PCI DSS if the third party is managing network infrastructure that comes into contact with CHD as is usually the case with private cloud environments.

For Platform as a Service (PaaS) and Software as a Service (SaaS), the third party will have to provide PCI compliance for the services they are providing to your organization.  That is because with either of these service offerings, the third party must have access to the CDE and will have the potential of coming into contact with CHD.

The problem with the majority of PaaS and SaaS vendors is that they only deal with your organization through a Web-based interface, i.e., everything is automated – contracts, support, etc.  As a result, the contract is a “take it or leave it” situation that does not usually cover everything needed for PCI compliance, there is no way to independently verify the representations made by the third party as well as the fact that the AOC provided by the third party typically only covers only the physical security requirements in requirement 9 and possibly some of requirements 11 and 12 and nothing related to the other requirements, even though the third party may have responsibilities for PCI compliance outside of what is represented in their AOC.

If this is the case, there is little you or any QSA can do to properly assess the environment to ensure it is truly PCI compliant.  As a result, we have a lot of organizations that try to develop compensating controls for these cloud implementations.  These organizations very quickly and frustratingly find out that there are very few, if any, controls on their side of the equation that can get them to “above and beyond” the original requirement.

I know there are a lot of other examples of services being provided to merchants.  But, hopefully these examples can assist you in clarifying what you need or do not need from your third parties when it comes to PCI compliance.

PA-DSS Validation Clarification

On July 23, 2012 we received the following communication from James Barrow, Director of AQM Programs, with the PCI Security Standards Council.  I found it worthy of posting so that everyone understands the procedures their QSA needs to follow regarding applications that are supposedly PA-DSS validated.

The Council has recently received inquiries related to the Validation of Payment Applications process and there seems to be some confusion related to the PCI SSC listing of validated applications.  The Council’s website is the authoritative listing of applications that have been accepted by the Council.  This is the listing that should be checked by the assessors during each engagement with a merchant.  If the merchant’s application (both name and version number) are not on this list, it cannot be considered validated.

There are some instances where a merchant might provide you with a document (not issued by the Council) stating that the application has undergone some type of review and has been deemed compliant.  However, if the payment application is not listed on the PCI SSC website, it cannot be considered validated.  If such an instance of this arises during one of your engagements, you as the assessor must perform your due diligence in determining if the application is capable of meeting all of the DSS requirements.

For the PA-DSS community we realize that some applications are not applicable to the PA-DSS program.  The eligibility for the program is contained in the document entitled “Which Applications are Eligible for PA-DSS Validation?  A Guiding Checklist” available at the Council’s document library.  If an application is not eligible for the program, it does not preclude you from performing an assessment.  However, at the end of the assessment you cannot communicate to your client that per the assessment the application has been “validated”, nor can the client (vendor) expect the assessment to have any bearing on a merchant’s ability to achieve DSS compliance.

Following the above guidance should help to remove any miscommunication or misunderstanding in the payment ecosystem as to what applications are considered validated, and the steps that need to be taken should a non-validated application be identified in the field.

The key here is that if the version of your payment application is not on the PCI SSC’s PA-DSS list, it is not considered PA-DSS validated and your QSA must assess it accordingly.  I cannot tell you how many merchants we encounter where they have a different version of the application, yet the merchant insists that we treat it the same as the version that is PA-DSS validated.

We also run into software vendors that insist that the version the merchant is running is not significantly different from the version that is PA-DSS validated.  While this could be an accurate statement, the vendor needs to have submitted the version to a PA-QSA for validation of that fact.  The PA-DSS has a procedure that the PA-QSA can follow to determine that version changes have not affected cardholder data processing and the application’s PA-DSS validation.  Without that validation, as a QSA, our hands are tied and we must conduct a full assessment of the application under the PCI DSS.

Much to the chagrin of a lot of merchants, a PA-DSS validation does not imply that they are PCI DSS compliant.  There is also this mistaken belief by merchants that a PA-DSS validation implies that the QSA does not have to assess the application.  Under the PCI DSS, a QSA still must assess the application’s implementation and ensure that it was implemented per the vendor’s instructions to maintain its PA-DSS validation.  The trouble is that this implementation assessment may not save much, if any, time for the QSA.

Unintended Consequences

Why reinvent the wheel?  This is from the June 2012 Assessor Update published by the PCI SSC.  It provides advice for those situations when people are foolish and transmit their cardholder data to your organization in ways you would prefer they do not use.  While focused on the merchant, these recommendations can be followed by all organizations that need to be PCI compliant.

What should a merchant do if cardholder data is accidentally received via an unintended channel?

Merchants sometimes find themselves in a situation where a customer provides their cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of capturing sensitive data.

In this situation, the merchant can choose to either include the channel into the scope of their cardholder data environment (CDE) and secure it according to PCI DSS, or implement measures to prevent the channel from being used for cardholder data.

Some suggestions for merchants to prevent any further capture of cardholder data via unsecured methods include:

•   Implementing controls to prevent acceptance of cardholder data via unsecured channels
•   Responding to customers in a manner which does not propagate any further unsecured transmissions of cardholder data
•   Implementing best practices and customer communications to proactively prevent customer use of unsecured channels for cardholder data

Cardholder data received via an unintended channel should be either immediately removed or secured according to PCI DSS and incorporated into the merchant’s CDE. If a merchant does not wish to bring a communication channel and its supporting systems into the scope of their CDE, controls should be in place to prevent the capture of cardholder data and/or to securely delete cardholder data from this channel before the data can be further stored, processed or transmitted.

If unsolicited cardholder data is received via an insecure method, the merchant should take immediate steps to minimize the security impact and prevent further exposure of that data. For example, if a merchant receives cardholder data in an email from a customer, the merchant’s personnel should be trained to not ‘reply’ using the same email that contains the cardholder data.
Instead, the merchant’s personnel should respond in a manner that does not further propagate the unsecured transmission of cardholder data.  This may be accomplished by removing all sensitive data from the email response before replying or by contacting the customer via an alternative communication channel to complete the transaction.

Merchants are encouraged to communicate with their customers on the risks of sending cardholder data through insecure channels, and to ensure their customers are aware of the merchant’s secure methods for submitting payment information. By proactively encouraging their customers to use only secure payment methods, merchants can reduce the amount of cardholder data received via unsolicited or insecure channels.

Why The Push For EMV Adoption In The United States?

Have you noticed all of the press lately regarding the Europay, MasterCard and Visa (EMV) card coming out of Visa?  It has been very hard to miss.  As a result, I started wondering about the purpose of this full court press for EMV.

Before getting into my post, I need to be clear that EMV only refers to the chip in the EMV card.  In the past I have gotten a lot of feedback from Visa when I referred to EMV as “chip and PIN” even though the world almost universally refers to EMV as “chip and PIN.”

With that disclaimer, since last August, Visa USA has been making a concerted effort to get merchants to adopt EMV.  Just a week or so ago, there was another push by Visa USA to entice merchants to support EMV.  So what is the driver behind this push?  That is the $64,000 question and the more you talk to processors and merchants, the more confusing it gets.

Merchants are just as puzzled as I am regarding Visa USA’s EMV push.  In the case of a number of large merchants I have spoken with, they do not get it as they refreshed their card terminals and POS equipment over the last three years and there is no way they are going to swap all of that new gear for EMV-capable equipment.  These merchants are not even looking at contactless terminals.  Such an equipment swap this soon would not be cost effective.

But merchants question what EMV would do for them.  EMV was developed in response to the fall of the Iron Curtain when fraud ran rampant in Europe.  Credit cards were being cloned at an obscene rate and card present fraud was huge.  When EMV was fully implemented, card present fraud in Europe went to levels close to or a little lower than in the United States and EMV card present fraud has remained around those rates since.  Given where card present fraud rates are currently in the United States, introducing EMV would have a limited effect on card present fraud and that would not be enough to offset the costs of implementing EMV or contactless terminals.

So if it is not card present fraud, it must be card not present fraud that Visa USA wants to address right?  Card not present fraud, particularly on eCommerce Web sites is running almost out of control.  I would like to say that this increasing fraud rate that is the reason for Visa USA’s push.  However, EMV does nothing to address the rapidly rising rates of card not present fraud.  The reason is that in order for EMV to address card not present fraud, there would have to be some sort of interface written that would produce codes, single use transaction numbers or similar that could be used by the consumer online.  But no such solution exists, so card not present fraud cannot be the driver either.

Back in August Visa USA announced that merchants using EMV or contactless could avoid filing a PCI Report On Compliance (ROC) with Visa USA, so that must be the reason for the push.  At this year’s PCI Community Meeting in Phoenix, Arizona, PCI SSC General Manager Bob Russo made it very clear that regardless of what Visa USA was saying about filing a ROC; all merchants were still required to prove that they are in compliance with the PCI DSS.  Other card brands also reinforced this statement by reaffirming that they still required the merchant’s ROC and/or AOC as proof of compliance.  As a result, merchants save themselves very little by not having to file a ROC/AOC with only Visa USA.

What about EMV being more secure?  While that is typically true for small and mid-sized merchants, large merchants that switch their own credit card transactions would still likely have card data in their switch systems if not elsewhere in their computer systems.  So claims by some, including at times Visa USA, that PCI compliance is easier with EMV are not totally true.  Large merchants in Europe will back this up.

So after 15 years of EMV, what is Visa USA trying to prove with this push of EMV?  Apparently only Visa USA can tell us because, for the rest of us, there are no business cases we can construct to justify the switch to EMV.  Obviously, Visa USA knows something that the rest of us do not.  Or do they?  I have consistently said that without any card not present fraud solution; EMV is just a solution looking for a problem.

But wait, maybe there is something here that we have been missing.  Is it possible that Google Wallet and similar current and future applications make Visa USA feel threatened?  There may be some factual basis in that statement.

At the PCI Community Meeting last fall, I spoke with a number of processors that seemed to have an idea of why Visa USA was finally pushing EMV.  These processors indicated that the EMV push was being driven by Visa USA to get EMV into the United States market before Google Wallet and similar applications could take the advantages of EMV away.  After all, the United States is the largest credit card transaction market in the world and if EMV was not in the United States, there is no driver to get worldwide adoption pushed.

When I quizzed these processors about the supposed “advantages” of EMV, they said that was the real problem.  With the advent of smartphones and applications such as Google Wallet, EMV has no advantages.  As a result, merchants and banks have no incentive to implement EMV with these new technologies just on the horizon.

When I went back and talked to a couple of key merchants, they all said that they are waiting out the technology race to see what wins from a smartphone perspective.  If Google Wallet and the contactless approach win, then that is where they will head.  However, a lot of merchants are betting on one-time use transaction codes displayed as bar codes to win out as they do not typically require any technology changes at their POS.  American Express went down the one-time use transaction code (15 digit number that appears like a credit card number) around five years ago, but only had limited success with it for online transactions.  However, maybe the time has come for another try.

In the end, it is the consensus of merchants and processors that Visa USA has missed the window for EMV in the United States.  Most organizations believe that if Visa USA wanted EMV in the United States, they should have pushed it long ago.

UPDATE:  American Banker and PaymentsSource are holding a Webinar entitled “The End Of The MagStripe?” on Tuesday, March 6, 2012, at 3PM EST.  Unfortunately, it is not free, it costs $99.  This Webinar purports to answer some of the questions I have posed here as well as some other interesting insights into Visa and MasterCard’s thoughts on EMV.

Merchant Beware – New Mobile Payment Solution Out In The Wild

Merchants need to be aware of a new mobile payment solution – Square from Square Inc.  A colleague pointed me to the Square site with the question, “Is this PCI compliant?”

Square appears to be a hardware/software solution for iPhones, iPads and Android devices.  It has a cute, square magnetic stripe reader for swiping cards, but also appears to provide the capability to manually enter cardholder data through these devices’ virtual keyboards.  This all appears to be similar to the iPhone that used to appear in the first Apple iPhone commercials that, for reasons that will become obvious, magically disappeared from their commercials very quickly and quietly.  It is also why Apple no longer uses iPhones or iPod Touches in their stores to process payments.

In referencing the PCI SSC’s PTS certification database, I could not find Square’s certification for the PTS standard.  Although, given the pictures on Square’s Web site, I really did not expect to find it certified to the PTS standard as there is no way it could meet the PTS standard.  Has Square submitted their solution for PTS certification?  It may have, but since the PCI SSC PTS certification database only lists those devices that have completed the certification process, there is no way for anyone to know if it has submitted Square until it is certified.  However, since the use of PTS certified devices is a requirement of all of the card brands, until Square is PTS certified, use of a Square device for processing of credit cards violates a merchant’s merchant agreement.  Game over.

While not complying with the PTS standard is a deal breaker in my opinion that is not the only PCI compliance issue.  In referencing the PCI SSC’s PA-DSS certification database, I could also not find the Square software application listed.  That situation was also not unexpected as the PCI SSC announced in a press release on June 24, 2011 that it was suspending the PA-DSS certification review of all mobile payment applications indefinitely.  As a result, there is no way Square’s software will be PA-DSS certified for the foreseeable future whether they submitted it for PA-DSS certification or not.  Not that the PA-DSS certification is a deal breaker for merchants to use the Square software, but it means that merchants using the Square software to process payments will have to have the Square software assessed to ensure it meets all of the PCI DSS requirements regarding payment applications.

And knowing what I know about all of these devices, I can guarantee that the Square software will not be PCI DSS compliant because all of these devices will store the cardholder data unencrypted for an untold amount of time until it is written over.  Even if Square’s software encrypts the data, the underlying OS will also collect the data in cleartext.  Forensic examinations of these devices have shown time and again that regardless of what the software vendor did, the data still existed in memory unencrypted.  And that unencrypted data in memory can exist in these devices for days, weeks to even months depending on transaction volume and other applications loaded on the device.  It is this surreptitious OS data collection activity, the security issues with other applications as well as other security concerns that caused the PCI SSC to suspend their PA-DSS certification activities of these applications.

There is only one solution that uses an iPhone or iPod Touch that is PTS and PA-DSS certified at this time and it is from Verifone.  The reason that Verifone’s PAYware solution is certified is that: (1) Verifone submitted it for the PCI certifications prior to the June 24 suspension and, the bigger reason in my book; (2) it relies on a digital back separate from the iPhone/iPod that performs the card swipe and all of the card data processing/transmission in a secure manner.  The iPhone or iPod Touch are used only as a display and cellular/Wi-Fi conduit for network connectivity.

The only other mobile payment solutions I am aware that are PTS compliant are purpose built credit card terminal using Wi-Fi or cellular communications.  These are considered terminals by the PCI SSC, so their underlying software is not required to be PA-DSS certified at this time, but they are required to be PTS certified.  In addition, these terminals have been in use in Europe for quite some time, so they are a proven secure solution.

The bottom line is that it is the merchant’s responsibility to ask vendors the right questions and weed out non-PCI compliant solutions.  The card brands and the PCI SSC are not in the business of regulating vendors, they leave that to the marketplace.

If you are looking for a PCI compliant mobile payment solution, talk to Verifone, Equinox, Ingenico or other recognized card terminal manufacturers as those are going to be your only PCI certified mobile payment processing options at this time.

UPDATE: I have had a number of people contact me about the certification status of the Square solution based on the fact that Square Inc. is listed on Visa USA’s Web site as a PCI DSS compliant service provider.  Remember, this listing only means that the card processing services provided by Square Inc. to their customers (i.e., all of the back office processing they do to process card transactions) are PCI DSS compliant, not that the devices that actually conduct the card swipe are certified PCI compliant.  A certified card terminal would be PCI PTS certified and the software running on the terminal would be PA-DSS certified.  The Square Inc. device that connects to iPhones and Android devices does not have that PCI PTS or PA-DSS certifications, therefore it should not be used for conducting credit card transactions.

UPDATE: Here is another solution that avoids the iPad altogether, Hubworks Interactive.  I spoke with them and their QSA and this product avoids the iPad by conducting the transaction in the digital framework surrounding the iPad.  The iPad is strictly used as a display and a Wi-Fi conduit.  The digital framework encrypts the cardholder data before it is ever seen by the iPad just as Mark Bower suggested would work.

UPDATE: July 25, 2012 – In the July issue of Transaction Trends, page 6, there is an announcement from Square that they are offering a new loyalty program for merchants using Square Register and Pay. Let us hope it is securely implemented as I am sure Square is using a customer’s PAN for tracking based on how they describe the program.

UPDATE: August 30, 2012 – The Square Web site is now implying that the transmission of card data is secured through “industry-standard encryption,” whatever that means.  There have been rumors that Square has implemented point-to-point encryption (P2PE) in their card readers but was not advertising that fact.  That is why I went to this page to see what, if anything, had changed.  However, based on the statements on this page, it appears that P2PE has not been implemented as you would think they would be touting that fact.

UPDATE: October 15, 2012 – A good friend of mine just started working at Square, so hopefully we can get to the bottom of how Square works and what risk there is to merchants using their solution.  Stay tuned.

Supermarket Chain Notifies Customers Of Self Checkout Skimming

Customers of Lucky Supermarkets, a subsidiary of Save Mart Supermarkets, got an early Thanksgiving gift when they were notified that 20 Lucky Supermarkets and one Save Mart store in California had discovered skimming devices inside those stores’ self checkout systems.  As retailers move to more and more automation surrounding checkout, the more risk they take on unless they put in place controls to minimize those risks.

Grocery stores can learn a lot from gas stations and convenient stores and the controls these organizations have put in place to secure gas pumps.

• Locks are keyed the same.  It turned out that gas pump manufacturers for as far back as they have had locks on pumps use the same keys.  I worked at a gas station when I was in high school a long, long time ago.  Yet, six years ago conducting a security review for a State Transportation Department, I found that the pump keys that I had neglected to return 30 years earlier would open the gas pumps at the maintenance garages.  Whoa!  Turns out self checkout manufacturers have the same problem unless you request them to use a different key and lock combination.  So the first lesson to learn is to explicitly request a unique to your organization lock and key set for your self checkout units.
• Locks are not perfect.  Even if you change out the locks, they can still be picked fairly quickly by someone who knows what they are doing.  So, for a second level of defense, you need to add serialized tamperproof tape to the doors that allow access to the inside of the self checkout unit.  Newer self checkout units only allow ease of access to change out the register tape and nothing else.  Only authorized technicians have the ability to gain access to the rest of the device.  However, best practice is to put serialized tape on all of the doors regardless.
• You may need tamperproof tape inside.  Older (age is all relative) self checkout units allow access to too much of the internal workings and/or do not have tamperproof parts inside the cabinet.  That means that “bad guys” can insert a skimmer without any obvious changes.  To avoid that problem, you can wrap connections with tamperproof tape so that if anyone attempts to take the connectors apart, it will be obvious upon inspection of the tamperproof tape.  Discuss your situation with your self checkout vendor as they can advise you on what should be taped.
• Locally monitor your equipment.  The serial numbers on the tape need to be recorded on a log sheet and the tape (inside and outside) should be checked at every manager shift change.  Any tape that appears to have been tampered with should be investigated and that unit taken out of service until an authorized technician deems it safe to put back in service.  In addition, video monitoring should be in place to monitor each self checkout.  Staff should be present at all time to monitor these devices.  Typically a single person can cover two isles compromised of a total of four self checkout devices.  Any more than that and your staff can be easily distracted and miss someone tampering with a device.
• Remotely monitor your equipment.  Most self checkout devices have the ability to be centrally managed and monitored.  In the event a door is opened, the unit can send an alert to the central monitoring console.  When an alert is generated, operations personnel should immediately contact the retail outlet and have store management immediately investigate the alert and inform the central monitoring station of the devices status.  If the store is not in operation, then the central operations personnel should contact local law enforcement and store management that an emergency exists at the store.

As a friendly reminder, security is not perfect.  These controls have to be executed perfectly every day, every year.  That is where things always go awry.  However, if you do execute these controls consistently, your organization should be very difficult to compromise.  The “bad guys” will know that and will find an easier target.