“Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:
Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.”

Again, for users of PGP or hardware security module (HSM), you should have no problem complying with the sub-requirements of 3.6.  For those that do encryption key management manually, you will have to implement detailed procedures to accomplish these requirements and this is who I am focusing this post.  However, keep in mind that the order in which I address the sub-requirements is not necessarily in PCI order.

Let’s first talk about key management in general.  The PCI DSS references the NIST key management procedures.  NIST has issued special publication (SP) 800-57 that is probably the best “bible” for encryption key management.  It goes into detail not only on encryption itself (volume 1), but also key management (volume 2) and discussion of special key management situations such as public key infrastructure (PKI), IPSec and others (volume 3).  For requirement 3.6, only volume 2 is likely relevant unless you are using IPSec, PKI or other special cases.

For those of you that are a service provider and you share cryptographic keys with your customers, you will need to document your policies, standards and procedures for securely sharing those cryptographic keys with your customers.

Under requirement 3.6.c are the secure key management practices that the PCI DSS requires.  These are where people seem to get off track and where NIST SP800-57 can provide you the greatest assistance.

Requirement 3.6.1 is the easiest and I have spoken on this topic in my post on encryption basics.  You need to generate strong encryption keys.  You should generate your encryption keys using a minimum of two people (your key custodians) and using a pseudo-random key generator such as the one available from Gibson Research Corporation (GRC).  Each key custodian enters their part of the key into the system and then the system uses those parts to encrypt the data.

Requirement 3.6.2 discusses how encryption keys are distributed and 3.6.3 is about how key parts are stored.  This is related to how your key custodians manage their part of the key.  Typically a key custodian will be assigned a safe where their key part is stored on paper or other unsecured media.  Only the custodian and their back up know the combination to the safe.  I have also seen PGP Zip or encrypted WinZip files used as the secure repository for key parts.  The idea is that key parts cannot be distributed in clear text.  And when the key parts are stored, they need to be secured.

Requirement 3.6.4 always seems to be a sticking point because people get caught up in the key expiration concept.  The primary thing to remember is that whether or not a key expires is typically related to the encryption algorithm used such as for those using public key infrastructure (PKI).  In most cases, the encryption keys do not expire, so this requirement is not applicable.  In those cases where the key does expire, you need to have procedures documented explaining how the key expiration process is handled.

This does bring up a good point about any encryption process and addresses requirements 3.6.5.a and 3.6.5.b.  There will be times when encryption keys need to be changed.  This most often happens when a key custodian changes roles or leaves the organization.  In those cases, you need to have a process in place to change the encryption keys.

One thing implied by requirements 3.6.5.a and 3.6.5.b is how do you know that an encryption key has been weakened or compromised?  Typically, your activities surrounding critical file monitoring will be the trigger that encryption keys have been compromised or have at least been attempted to be compromised.  You should be monitoring the encryption process as a critical file as well as the encrypted encryption keys if you are storing them on a server or other computer system.  Should your file monitoring indicate that these files are being tampered with, you need to change your keys.

Requirement 3.6.6 is all about the manual management of encryption keys by key custodians and the need for no one individual to know the entire encryption key.  Obviously this requires at least two people to be involved, but you need to have backups for those people, so it really is a minimum of four people.  I have seen instances of three and four primary key custodians, however, going beyond that seems a bit much.

Requirement 3.6.7 is all about change control in making sure that key changes require authorization and that unauthorized changes cannot go unnoticed.  Management approval of encryption key changes is a straight forward concept and should be a concept already implemented for change control.  However, people seem to get balled up in the unauthorized key change concept.  Again, your critical file monitoring processes should catch these attempts.

Requirement 3.6.8 requires that all key custodians are required to formally acknowledge their responsibilities in managing and protecting any encryption keys in their custody by signing an agreement to that effect.  This does not have to be some long and lengthy document, just a single page that indicates that the individual has access to the encryption key parts and that they agree to keep those parts secure and protected.

And there we have it.  If you have read the entire series, you should now have a very basic understanding of encryption and encryption key management.  You are not an expert, but you should now have a basic understanding of the concepts and controls surrounding encryption.

To refresh everyone’s memory, three and a half years ago, MasterCard issued a directive that by June 30, 2010, all Level 2 merchants needed to either: (1) have a PCI SSC certified Internal Security Assessor (ISA) prepare their Self-Assessment Questionnaire (SAQ) or, (2) have a PCI SSC certified Qualified Security Assessor (QSA) conduct a PCI assessment and issue a Report On Compliance (ROC).

Because of the uproar this directive caused with their Level 2 merchants, MasterCard backed off on the 2010 date but set forth a new date of June 30, 2012.  Now jump to the present, it is January 2012 and the calls from Level 2 merchants are starting to ramp up.  These merchants are now in a panic because, guess what?  Level 2 merchants put the ISA/ROC issue on the back burner and forgot about it until just now and they cannot afford to meet this requirement.  Oops!

I have sent a message to MasterCard to confirm that the June 30, 2012 date is still valid.  Until I have confirmation, if you look at MasterCard’s Web site, the June 30, 2012 date is still posted as the date you will need to meet the aforementioned requirements.

For all of you Level 2 merchants that accept MasterCard, I would highly recommend that you contact your acquiring bank and confirm the SAQ and ROC reporting requirements.

UPDATE: MasterCard confirmed on Thursday, January 26, 2012, that the June 30, 2012 date is going to be enforced.

What should rile merchants is a quote that comes from David Navetta, founding partner of the Information Law Group, who states,

“Most QIRAs (qualified incident response assessors) do not necessarily do a deep-dive forensic assessment.  Rather, they do something more tailored to the task of confirming PCI compliance and validating the existence of a card breach.  Unfortunately for merchants, we have found that some of the assumptions made by QIRAs in this context are often not favorable to the merchant.”

To be fair, there are two issues here.  One is a breach of data and the other is compliance with the PCI standards.  In regards to compliance with the PCI standards, if you were breached, what is the likelihood you were PCI compliant at the time of the breach?  It does not take a rocket scientist to figure that out, let alone some QSA or PFI (PCI Forensic Investigator) coming in after the fact.  In fact, even without any analysis, I would say that your compliance with all of the relevant PCI standards at the time of the breach was probably somewhere between slim and none.

However, this lawsuit points out an even more disconcerting issue with a cardholder data breach.  What Mr. Navetta is pointing out is that any incident investigation initiated by the card brands under the PCI standards is going to focus on PCI compliance and not on whether or not the breach actually occurred.  What a piece of comforting news that should be to merchants.  The card brands know that you were not in compliance with the PCI standards, yet they go through the motions of an “investigation” just for appearances.

But the most troubling thing of all, and the point that should scare all merchants, is the indication that Visa and MasterCard did not even conduct an investigation into the breach and how it occurred.  The article implies that Visa and MasterCard implicated the merchant based on an analysis of the fraudulent transactions.  That transactional analysis led the card brands back to a common point, the merchant that filed suit.  And as the following examples show, the card brands’ all knowing analyses are not always the entire story.

I can tell you from experience with some of our clients that this happens all of the time.  A number of our clients have been involved in these card brand driven “witch hunts.”  The card brands point the finger at a number of merchants because of the fact that the merchants all came into contact with the cards involved.  Unless you have the wherewithal to prove you are not the reason for the fraud, you are the reason the breach occurred.

As an example, back in the ancient times when the Visa CISP ruled the land, we were involved in the forensic examination of a client that is a franchisee of a restaurant chain.  Visa informed them that one of their restaurants was the source of a cardholder data breach.  Their “evidence” was a report that showed their restaurant had come into contact with the cards involved in fraud.  Their attorney asked Visa to explain how this analysis was proof that no other merchant could have been the cause of the breach?  The attorney also asked if any other merchants had also come into contact with the cards in question.  Visa told their attorney that it was proprietary information and that they could not share that information.

Since our client was getting nowhere with Visa, they asked us to conduct a forensic examination of the computers involved to see if a breach had occurred.  While we found a number of improvements in security that should be made, we were not able to find any evidence of the card numbers in question on any of his systems that could have come into contact with the cardholder data.  When presented with this information, Visa replied to our client and their legal counsel that it did not matter as their restaurant was the source of the breach.  In the end, our client paid Visa the equivalent of a third of a year’s profit as their fine to resolve the situation.

As Paul Harvey liked to say, “And now, the rest of the story.”  It turned out our client actually was involved in the data breach, albeit indirectly.  Skip ahead a half a year at the same restaurant.  One day the police walk in and arrest an employee for skimming credit cards.  As the police continued investigating, it turned out there were two more employees that were also skimming cards.  Did Visa apologize or return the “fine” they collected.  Heavens no, our client was still guilty as far as Visa was concerned.

In another case only a couple of years ago, the same situation occurred.  This time our client was a very large Midwestern retailer with a store in the same town where the fraud was occurring.  When approached with the fraud analysis report, the retailer’s legal team ambushed Visa’s representatives and got them to admit that there were four other potential outlets that could also be the source of the breach.  However, in retaliation, Visa implicated our client in the breach through various local media outlets.  The retailer involved us in some due diligence regarding their PCI compliance and other potential issues surrounding the possibility they were the source of the breach.  In the end it turned out that a convenience store in town was the actual source of the breach.  The overnight convenience store clerk had allowed a friend to doctor the ATM in the store to skim cards.  While Visa dropped their “investigation” with our client, they never once apologized for accusing our client of being the source of the breach or the inconvenience they caused with their “investigation.”

The lesson to be learned here is that the card brands are very heavy handed when dealing with a breach.  While I understand their motives for this approach, I also feel it is also very one sided in the favor of the card brands.  I know they are trying to protect their brand names.  But in the end, such heavy handedness will only alienate merchants and, in the end, customers who use their cards to pay for goods and services.

It will be interesting to see how this lawsuit plays out.

Hardware security module (HSM) solutions typically provide facilities for strong key creation as well as a secure storage mechanism for keys.  A prime example of this concept is with the Trusted Platform Module (TPM) that is now standard on notebook computers.  I will try to point out the differences with these various approaches as I move through the discussion.

So with that as a background, let us start into our discussion of requirement 3.5.  The overall goal of requirement 3.5 is stated as:

“Protect any keys used to secure cardholder data against disclosure and misuse:  Note: This requirement also applies to key-encrypting keys used to protect data-encrypting keys—such key-encrypting keys must be at least as strong as the data-encrypting key.”

Typically, the first question I get is, “What in the world is a key-encrypting key?”  I need to push this question off, as there are other questions that need to be addressed before a meaningful discussion of the key-encrypting key (KEK) can occur.

With the key-encrypting key question put on the back burner, the second question most people ask is how does one accomplish protection of encryption keys?  In the case of PGP, that is the responsibility of the key owner not to disclose their passphrase.  It is the role of the HSM key repository to protect and manage keys.  If your encryption solution does not provide a secure repository for your encryption keys, then you need to provide such a capability.

When you have PGP or HSM, then protecting encryption keys is built-in.  A manual option is to store you encryption keys on paper or removable storage media and store the paper or removable media in a safe.  The problem with the manual option is that encryption keys are typically needed to boot the secure server or start an application that needs access to encrypted data.  The security surrounding the keys becomes problematic at best as operations personnel need regular access to the keys in order to keep systems and applications running.  As a result, most organizations desire to have their keys stored electronically for ease of access by servers and applications.

This now brings us to the concept of a KEK.  If you desire electronic storage of encryption keys, then you need to ensure their security.  If you store encryption keys in a folder on another server, you need to not only restrict access; you also need to encrypt them so that should someone copy the folder, they cannot read the keys.  To accomplish that, you encrypt the encryption keys wherever they are stored and then secure the key encrypting key (aka KEK).

This is where requirements 3.5.1 and 3.5.2 come into play.  These requirements are focused on ensuring that if an organization has taken the approach of managing their own encryption keys and electronically storing them, the keys are properly secured and managed by as few persons as feasible.

That does not mean that those of you using PGP or HSM are not responsible for also complying with requirements 3.5.1 and 3.5.2.  It is just that those of you using PGP or HSM likely have an easier time complying as both technologies can provide their own solutions for meeting these requirements.

In a future entry, I will discuss requirement 3.6.

Hashing comes up in requirement 3.4 which says:

“Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: one-way hashes based on strong cryptography (hash must be of the entire PAN), truncation (hashing cannot be used to replace the truncated segment of PAN), index tokens and pads (pads must be securely stored), strong cryptography with associated key-management processes and procedures.”

Before we get into hashing algorithms, I need to make sure everyone is clear that hashing is a one-way operation.  Unlike encryption, you cannot reverse data that has been hashed.  So if you are considering using hashing, you need to make sure that you will never need the original information such as a PAN.

Probably the most common one-way hash algorithm is SHA-1.  Unfortunately, it has been proved that SHA-1 has some issues that make it not as secure as its later iteration, SHA-2.  As such, those of you using SHA-1 should be migrating to SHA-2 or another hashing algorithm.  Those of you considering a solution that relies on SHA-1 should be asking the vendor if SHA-2 or another secure algorithm can be used.

The other most common one-way hashing algorithm is RSA’s Message Digest 5 (MD5) algorithm.  Like SHA-1, MD5 has also been deemed no longer acceptable due to a number of issues that make it no longer secure.  As a result, users of MD5 are recommended to migrate to RSA’s MD6, SHA-2 or another hashing algorithm.  And just so you are not confused, MD5 is still commonly used as a way to generate a checksum for confirming the validity of a download which is an entirely different purpose than what I am discussing here.

And to show you that things do not stand still in the cryptographic hashing world, the United States National Institute of Standards and Technology (NIST) is in the process of selecting the winner of their SHA-3 competition.  That winner will be announced sometime in late 2012.

While you can use a hash function “as is,” security professionals typical recommend the addition of a “salt” to complicate the result of the resulting hashed value.  A salt is two or more characters, usually non-displayable binary values, appended to the original value, in our example the PAN.  The salt adds a level of complexity to the resulting hashed value thus making the use of rainbow tables to break hashed values more difficult, if not impossible, to use.

One useful thing you can accomplish with a hashed value is that you can still use it for research as long as you are not using a rotating salt.  That means that the hashed PAN should have the same hashed value every time the same PAN is hashed.  This can be very important for fraud investigators and anyone else that needs the ability to research transactions conducted with the same PAN.  If these people do need the actual PAN, they will have to go to a different system that stores the encrypted PAN or go to their card processor for the PAN.

The PCI DSS issues a warning about using hashing and truncation together.  There is a note in requirement 3.4 that states:

“It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN.  Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.”

This note is more relevant to situations where the truncation is the first six digits AND the last four digits.  However, it brings up a good point regarding all methods of information obscuring including encryption.  Never, ever store the obscured value along with the truncated value.  Always separate the two values and also implement security on the obscured value so that people cannot readily get the obscured value and the truncated value together without oversight and management approval.

Hopefully now we all have a base level knowledge of hashing.

For the security and encryption purists out there, I do not represent this post in any way, shape, or form as the “be all, to end all” on encryption.  Volumes upon volumes of books and Web sites have been dedicated to encryption, which is probably why it gets the bad reputation it does as the vast majority of these discussions are about as esoteric as they can be.

In addition, this post is written in regards to the most common method of encryption used in encrypting data stored in a database or file and that is the use of an encryption algorithm against a column of data or an entire file.  It does not cover public key infrastructure (PKI) or other techniques that could be used.  So please do not flame me for missing your favorite algorithm, other forms of encryption or some other piece of encryption minutiae.

There are all sorts of nuances to encryption methods and I do not want to cloud the basic issues so that people can get beyond the mysticism.  This post is for educating people so that they have a modicum of knowledge to identify hyperbole from fact.

The first thing I want to clarify to people is that encryption and hashing are two entirely different methods.  While both methods obscure information, the key thing to remember is that encryption is reversible and hashing is not reversible.  Even security professionals get balled up interchanging hashing and encryption, so I wanted to make sure everyone understands the difference.

The most common questions I get typically revolve around how encryption works.  Non-mathematicians should not need to know how an encryption algorithm works, that is for the experts that develop and prove that they work.  In my opinion, unless you are a mathematician studying cryptography, I recommend that people trust the research conducted by the experts regarding encryption algorithms.

That is not to say you should not know strong cryptography from weak cryptography.  I am just suggesting that the underlying mathematics that defines a strong algorithm can be beyond even some mathematicians, so why we expect non-mathematicians to understand encryption at this level is beyond me.  My point is that the algorithms work.  How they work is not and should not be a prerequisite for management and even security professionals to using encryption.

This leads me to the most important thing people need to know about encryption.  If you only take away one thing from this post, it would be that strong encryption comes down to four basic principles.

• The algorithm used;
• The key used;
• How the key is managed; and
• How the key is protected.

If you understand these four basic principles you will be miles ahead of everyone else that is getting twisted up in the details and missing these key points.  If you look at PCI requirement 3, the tests are structured around these four basic principles.

On the algorithm side of the equation, the best algorithm currently in use is the Advanced Encryption Standard (AES).  AES was selected by the United States National Institute of Standards and Technology (NIST) in 2001 as the official encryption standard for the US government.  AES replaced the Data Encryption Standard (DES) that was no longer considered secure.  AES was selected through a competition where 15 algorithms were evaluated.  While the following algorithms were not selected as the winner of the NIST competition, Twofish, RC6 and MARS were finalists and are also considered strong encryption algorithms.  Better yet, for all of you in the software development business, AES, Twofish and MARS are open source.  Other algorithms are available, but these are the most tested and reliable of the lot.

One form of DES, Triple DES (3DES) 168-bit key strength, is still considered strong encryption.  However how long that will remain the case is up for debate as 3DES 168-bit was recently broken for up to six character key lengths using the Amazon EC3 cloud.  I have always recommended staying away from 3DES 168-bit unless you have no other choice, which can be the case with older devices and software.  If you are currently using 3DES, I highly recommend you develop a plan to migrate away from using it as soon as you can, as it is just a problem waiting to happen.  New implementations of encryption should never even consider 3DES as an option.

This brings up another key take away from this discussion.  Regardless of the algorithm used, they are not perfect.  Over time, encryption algorithms are likely to be shown to have flaws or be breakable by the latest computing power available.  Some flaws may be annoyances that you can work around or you may have to accept some minimal risk of their continued use.  However, some flaws may be fatal and require the discontinued use of the algorithm as was the case with DES.  The lesson here is that you should always be prepared to change your encryption algorithm.  Not that you will likely be required to make such a change on a moment’s notice.  But as the experience with 3DES shows, what was considered strong in the past, is no longer strong or should not be relied upon.

Just because you use AES or another strong algorithm does not mean your encryption cannot be broken.  If there is any weak link in the use of encryption, it is the belief by many that the algorithm is the only thing that matters.  As a result, we end up with a strong algorithm using a weak key.  Weak keys, such as a key comprised of the same character, a series of consecutive characters, easily guessed phrase or a key of insufficient length, are the reasons most often cited as why encryption fails.  In order for encryption to be effective, encryption keys need to be strong as well.  Encryption keys should be a minimum of 32 characters in length.  However in the encryption game, the longer and more random the characters in a key the better, which is why you see organizations using 64 to 256 character long random key strings.

This brings us to the topic of encryption key generation.  There are a number of Web sites that can generate pseudo-random character strings for use as encryption keys.  To be correct, any Web site claiming to generate a “random” string of characters is only pseudo-random.  This is because the character generator algorithm is a mathematical formula and by its very nature is not truly random.  My favorite Web site for this purpose is operated by Gibson Research Corporation (GRC).  It is my favorite because it runs over SSL and is set up so that it is not cached or processed by search engines to better guarantee security.  Using such a site, you can generate keys or seed values for key generators.  You can combine multiple results from these Web sites to generate longer key values.  In addition, you can have multiple people individually go to the Web site, obtain a pseudo-random character string and then have each of them enter their character string into the system.  This is also known as split key knowledge as individuals only know their part of the total key.

Just because you have encrypted your data does not mean your job is over.  Depending on how your encryption solution is implemented, you may be required to protect your encryption keys as well as periodically change those keys.  Encryption key protection can be as simple as storing the keys on paper in a sealed envelope or on an encrypted USB thumb drive in a safe to as complex as investing in a key management appliance.

Finally, key changes are where a lot of organizations run into issues.  This is because key changes can require that the information be decrypted using the old key and then encrypted with the new key.  That decrypt/encrypt process can take days, weeks even years depending on the volume of data involved.  And depending on the time involved and how the decrypt/encrypt process is implemented, cardholder data can potentially be decrypted or exposed because of a compromised key for a long period of time.

The bottom line is that organizations can find out that key changes are not really feasible or introduce more risk than they are willing to accept.  As a result, protection of the encryption keys takes on even more importance because key changes are not feasible.  This is another reason why sales of key management appliances are on the rise.

That is encryption in a nutshell, a sort of “CliffsNotes” for the non-geeky out there.  In future posts I intend to go into PKI and other nuances to encryption and how to address the various PCI requirements in requirements 3 and 4.  For now, I wanted to get a basic educational foundation out there for people to build on and to remove that glassy eyed look that can occur when the topic of encryption comes up.

Based on ViaForensic’s analysis, it appears that Google Wallet would likely comply with the PA-DSS.  The full PAN is encrypted and communication of the PAN via Wi-Fi or NFC is secured.  Granted there are a lot of other PA-DSS requirements that we do not have a window into that may or may not be PA-DSS compliant.  But on the whole, I would have to believe that Google Wallet would be PA-DSS certified.  So, why is Google Wallet not PA-DSS certified?

First and foremost, in the eyes of the PCI SCC and the card brands, Google Wallet and similar applications are storing pre-authorization data and are just an electronic representation of someone’s traditional wallet.  The PCI SSC does not certify traditional wallets, so why would they certify electronic wallets?  As a result, the PA-DSS does not apply.  Should Google and other vendors of electronic wallets ensure the security of cardholder data?  No doubt about it.

But a more important reason that the PCI SSC is backing away from certification is related to the other findings in ViaForensic’s report.  Their analysis also uncovered some not so good news in that Google Wallet stores a lot of personally identifiable information (PII) unencrypted.  This PII includes such information as cardholder name, expiration date, credit limit and account balance.  I think most people would now start to understand why the PCI SSC backed away from certifying such applications.

The PCI SSC does not want to be on the hook for the unsecured PII.  If the PCI SSC were to certify Google Wallet as PA-DSS compliant, I am sure their lawyers informed them that such a certification would drag them into lawsuits involving the exposure of the unsecured PII even though the PA-DSS does not cover PII outside of the PAN.  Their lawyers probably advised them that a PA-DSS certification would likely imply to users of these electronic wallet applications that their PII was included in the PA-DSS certification.  As a result, the PCI SSC and card brands would likely have to launch a massive and costly educational campaign to explain to the public that the PA-DSS certification was only related to protection of a cardholder’s PAN and nothing else.  And even with such a campaign, the PCI SSC would likely still get dragged into lawsuits over peoples’ PII being exposed.

And the likelihood of such lawsuits is very high.  Smartphones are regularly lost and the security protecting them is almost non-existent, if security is even enabled.  A hacker can easily take a lost smartphone and obtain enough information to perform identity theft.  Hackers could even decrypt the PAN given the high likelihood that the PIN to decrypt the PAN could be derived from other information on the smartphone.  The nightmare scenario would be development of malware delivered through the smartphone’s application store that harvests the PII.

At the end of the day, there is just too much risk involved in certifying such applications because there is just no way to manage the risk.  So those of you thinking the PCI SSC should certify these applications need to rethink your position.

FYI  This is my 200th post.  I never guessed that this blog would last this long and I want to take this time to thank all of you for keeping this going.

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.

Defining The Cardholder Data Environment

The first step in any PCI assessment is determining the extent of an organization’s cardholder data environment (CDE).  However, it should come to no surprise to anyone that defining an organization’s CDE can be difficult even in the smallest of organizations.

The first question is who is responsible for defining the CDE?  Until the release of the PCI DSS v2.0, this was not clear, but had always been implicitly defined by the PCI SSC and the card brands as the responsibility of the organization, not the QSA.  The QSA’s role is to take the CDE definition provided by the organization and confirm that the CDE definition is accurate based on the QSA’s assessment work.

The next question that inevitably comes up is how does an organization prove that its CDE is its CDE?  There are a variety of things an organization can do to define their CDE.  The first thing to do is to document the cardholder data flow.  This effort should define all of the applications involved as well as which applications actually store cardholder data.  Once the data flow is defined, then an organization should develop a network diagram that documents all of the firewalls, routers, switches, access points, servers and other network devices and how they are architected.

The final step in proving the extent of the CDE is for the organization to scan their entire network to confirm that cardholder data is not stored anywhere outside of the CDE.  For organizations that have invested in data loss prevention (DLP) technology, it usually means setting their DLP solution to look at all computers on their network and determine if any unencrypted cardholder data exists anywhere outside of the proposed CDE.  However, some DLP solutions have not capability to look at data stored in databases, so just because you have a DLP solution does not mean you have searched everything.

For those organizations that do not have a DLP solution, the process is the same but possibly a bit more complicated.  For organizations that have a budget, they can license GroundLabs’ Enterprise Recon utility to scan their network and databases.  For smaller organizations, GroundLabs also has Card Recon that it licenses on a number of PCs/servers basis.  There are also free or open source utilities available such as Spider from Cornell University, SENF from the University of Texas and CCSRCH from Sourceforge.  I personally prefer Spider from Cornell as I think it finds the fewest false positives of the three free utilities.  However, none of these utilities can scan a database and find cardholder data stored in a database.  And just so we are clear, all of these utilities are no absolute guarantee that an organization has truly found all cardholder data they may have stored on systems.  But, it is better than have done nothing.

For organizations that are not using a utility that understands database scanning, there is a manual way to conduct your assessment.  Unload any credit card account number (PAN) fields as well as all comment fields into a CSV or similar file format and then use whatever utility you are using to scan those files for cardholder data.

Networks and Managed Service Providers

Networks that are used to transmit cardholder data in the clear are always in scope – no exceptions.  Where things seem to get confusing for people is when encryption is brought into the mix.  However, going back to the original definition, if cardholder data is in the clear, then that portion of the network is in-scope.  But, believe it or not, this just creates more confusion and arguments.

The bottom line is that any network encryption endpoints are also always in-scope.  That is a statement that I have almost come to blows over more than once with managed service providers (MSP) that thought their devices and network were totally out of scope because of encryption.  In a lot of these instances, the MSP is the one managing the encryption keys and since they managed those endpoints and the related encryption keys, those endpoints are in-scope for PCI compliance and so are the MSP’s policies, standards and procedures for managing those devices (Requirements 1, 2 and 4) and keys (requirements 3.5 and 3.6).

“But the cardholder data is encrypted,” is the common refrain from the MSP.  Agreed.  But a QSA still needs to gauge compliance for the endpoints, not the connectivity between the endpoints.  However, MSPs argue that the endpoints are also out of scope because of encryption.  That would be right if someone other than the MSP managed the encryption keys.

Another battle QSAs run across is about MPLS networks.  At this year’s PCI Community Meeting, the question of MPLS networks being private was brought up and discussed.  What the PCI SSC and the card brands told QSAs is that it is up to the QSAs to confirm that the networks are in fact private.  That means that QSAs are going to have to examine the configuration of the endpoint routers to ensure that the MPLS network is in fact private.  I can tell you that this will put QSAs in a battle with a number of carriers who treat their MPLS networks and their configuration as intellectual property.  I can tell you from personal experience that these battles to get carriers to reveal their configurations can become very contentious and downright ugly.

The bottom line is that a lot of MSPs do not agree with their activities being in-scope and they refuse to allow an assessment of their environment where their activities are in-scope.  In those instances, we have no choice but to mark the client as not having those requirements in place.  I have constantly asked MSPs that fight us to explain why the MSP is not responsible when the client cannot respond to the requirement because the MSP performs that function?  More often than I would like to admit, we get the “trust us” response.  In a few instances, I have been told that, “The PCI SSC and card brands never meant it to be treated that way.”  Really?  Because in QSA training the PCI SSC has been very consistent on the explanation of what is in-scope and MSPs are in-scope if they perform functions that are required to comply with the PCI standards.  While the majority of MSPs have come to this realization, there are still holdouts out there that still refuse to cooperate.

Applications

Applications that process, store or transmit cardholder data are always in-scope – period.  I think everyone understands that statement; however, it is the nuances within applications that create the problems.

In today’s integrated application environment, it is no wonder that determining what applications are in-scope is difficult, if not impossible.  Most organizations have gotten out of the complete application development game and are now in the application package integration game.  As a result, organizations are relying more and more on the application package vendors to understand data flow, particularly cardholder data flow.  While the PA-DSS process has greatly helped in getting data flow diagrams, there are still a lot of credit card processing applications where the data flow diagram is just not supplied.

Then we have “middleware” that further obscures things.  Middleware reformats information streams so that one application package can communicate with another application package.  The biggest problem with middleware comes from the fact that a lot of application integration teams are not really sure as to whether the cardholder data is in cleartext or encrypted.  The other problem we have encountered with middleware is the lack of security surrounding the administration consoles of the middleware.  Most middleware consoles are browser-based and can be accessed by anyone on the network.  Worse yet, a lot of these consoles can have serious security issues that make then susceptible to compromise.

Hopefully this explains the most common issues we see with scoping PCI assessments.  If you have any situations where you question scoping, please share them with the group and hopefully we can explain what is in-scope and what is not in-scope.

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.