Archive for August, 2011


Compliance Is Not Security – Busted!

You hear this as a common lament from security professionals, “Compliance is not security.”  This remark has always sounded like a dodge to me.  I suppose the reason I think this is that a majority of the people who seem to utter this phrase always seem to have questionable security practices.  But since I hear this complaint so much, I thought I should see if these people have a point.  So like Jamie and Adam on Mythbusters, I decided to see if this saying really held water.

The first thing I did was to get the definition for the term ‘compliance’.  From Webster’s dictionary, ‘compliance’ is defined as:

“Conformity in fulfilling official requirements.”

That definition seems to say it all.  If you are conforming to defined requirements, then you are compliant.  Therefore, whether or not an organization is secure comes down to whether or not the requirements they are complying with are deemed adequate to ensure the security of the organization.  So, it is the standard that is the problem, not the compliance with the standard.  Let us examine the PCI DSS for its completeness in creating a secure environment.

First, the PCI DSS is organized into six domains and twelve requirements.  The six domains are:

  • Build and Maintain a Secure Network
  • Protect Cardholder Data
  • Maintain a Vulnerability Management Program
  • Implement Strong Access Control Measures
  • Regularly Monitor and Test Networks
  • Maintain an Information Security Policy

The naysayers in the group will point to the fact that the PCI DSS seems to be exclusively focused on the security of cardholder data.  While true, I would argue that the following domains are required across an organization’s network to ensure the security of cardholder data.

  • Build and Maintain a Secure Network
  • Maintain a Vulnerability Management Program
  • Implement Strong Access Control Measures
  • Regularly Monitor and Test Networks
  • Maintain an Information Security Policy

So we only lose the second domain of “Protect Cardholder Data” when we focus on the cardholder data aspects.  There are still five of the domains remaining that are relevant to an organization’s entire network.  And even if those are focused on the cardholder data environment, in order to ensure the security of the cardholder data environment, security would have to exist on the other areas of the network not part of the cardholder data environment.  However, change cardholder data to employee data, contract data, board of director meeting minutes, customer data, product engineering data, and you begin to see that the PCI DSS can provide a framework for all of those sensitive data types as well.  As a result, I would argue that the PCI DSS does offer a reasonable framework for providing security.

Now, just so you know I have not taken a big gulp of the “PCI Kool-Aid.”  Is the PCI DSS the perfect security framework?  Not at all.  For that matter, there is no security framework that has been developed that is 100% perfect.  They all have their own flaws and problems, but for the most part they do an admirable job in securing an organization if properly implemented, monitored and tweaked.  But let us be clear, there is no such thing as a perfect security framework because as I have said time and again – wait for it – security is not perfect.  For those of you that are implicitly selling security to your management as perfect need to stop it.  You are doing the security profession a disservice and are likely cutting your career short as well.

The real reason I think a lot of security professionals regurgitate the saying; “compliance is not security” is that they are confusing compliance with consistency.  True security requires 100% consistency in the execution of procedures.  However, not all security can be totally automated and some security practices must involve people.  Unfortunately, people are fallible, so 100% consistency is not possible when people are involved.  Because we know people are fallible, we develop our security practices such that there are layers to protect us from the occasional missteps of people.  Those layers are structured around the control triad of protective controls, detective controls and corrective controls.  I have written on the control triad before, so I will not bother to explain these principles.  Needless to say, if your controls do not have these three components, then you are likely not as secure as you might think.

Because at some point people are involved in any control environment, compliance programs are developed to test an organization’s controls over a period of time to ensure that all standards and procedures are executed all of the time.  Compliance programs use frameworks such as the PCI DSS, SOX, HIPAA and the like to determine what areas to assess and to ensure that the requirements documented in these frameworks are being consistently followed.  But the key is that controls are assessed over a period of time, usually six to twelve months.  Assessees are required to provide proof over the assessment period to prove that controls are being enforced 100% of the time.

This is an area where the PCI DSS falls short as a lot of the requirements are only assessed as of a given point of time.  Unfortunately, that given point in time can be different for each requirement.  As a result, it is very easy for an organization to be compliant on paper, but not compliant consistently.  If the PCI SSC could make one change that would improve the PCI assessment process it would be to require assessing organizations over a period of twelve months.  I know of a few QSACs that follow such an approach, but they are few and far between.

The bottom line is that security professionals need drop the “compliance is not security” mantra as long as the framework used addresses all aspects of security.  All of you out there that are hiding behind this saying need to find some other excuse for not securing your organizations.  “Compliance is not security” is an excuse, and a lame one at that.  Because if you are truly doing your job, then you are complying with some security framework and, therefore, compliance is security.

Myth busted!


Kicked Out Of “The Club”

It has finally happened.  A Qualified Security Assessor Company (QSAC) has finally had their status revoked by the PCI SSC.  In a little noticed release dated August 4, 2011, the PCI SSC announced through an FAQ that as of August 3, 2011, Chief Security Officers (CSO) of Scottsdale, Arizona is no longer a QSAC.  To add insult to injury, CSO was also a Payment Application Qualified Security Assessor Company (PA-QSAC) as well and that status has also been revoked.  In reviewing CSO’s Web site, all references to merchant and application assessments have been removed which was likely required by the PCI SSC with the revocations.  These revocations are pending any appeal by CSO and only they know if an appeal will be mounted.

The PCI SSC did not explicitly share the reasons why CSO’s statuses were revoked.  But based on what little information is in the FAQ, it seems to imply that CSO was not able to provide documentation that supported their conclusions regarding the assessment opinions in their Reports On Compliance (ROC) and Reports On Validation (ROV) they had issued.  While there is no public way to determine the number of ROCs that CSO has issued, in reviewing the PA-DSS certified applications list from the PCI SSC Web site, CSO had issued around 56 ROVs for payment applications.

What is interesting about this whole situation is that the PCI SSC issued the announcement as an FAQ versus the usual press release.  From the FAQ, we now know something about the revocation process.

  • First and foremost, it seems that the PCI SSC is finally showing its teeth regarding their quality assurance assessment process.  The FAQ states, “CSO’s status as a QSA and PA-QSA was revoked only after careful review of reports and evidence submitted as part of the quality assurance program …”.  The implication here is that CSO was unable to provide sufficient evidence that supported the conclusions of their assessments.  The reason this is important is it seems to indicate that the PCI SSC is now including a review of work papers to determine if QSACs are collecting evidence that supports their conclusions in the Report On Compliance (ROC).
  • The FAQ states, “It accompanies CSO’s inability to demonstrate sufficient improvement through a prior remediation process.”  CSO had already been through the QA process once and had to go through remediation as a result of the prior QA review.  CSO must have gone through the remediation process within the last two years as it was two years ago when the QA process started.  Even after going through remediation, CSO was apparently not able to get through the QA assessment without being placed in remediation again.  What is unclear is whether a QSAC is not allowed to go through remediation twice in a row or if the CSO situation was the outgrowth of larger QA issues that could not be corrected.
  • The FAQ states that ROCs and ROVs issued by CSO and accepted by the card brands and the PCI SSC are still valid, but that any work in process will need to be conducted by a different QSAC or PA-QSAC.  What I find interesting here is that while the PCI SSC QA process found that CSO was not doing their job as a QSAC or PA-QSAC, merchants and others are to accept their previously issued work and results.  That seems a bit too flexible in my opinion.  If CSO’s status as a QSAC and PA-QSAC has been revoked, particularly for being unable to support their conclusions, then why should any organization accept their conclusions on any previous assessments?  I am particularly concerned about any payment applications certified as PA-DSS compliant.
  • One thing implied by the FAQ but not explicitly stated is that all of CSO’s employees that had a QSA designation are no longer QSAs.  As a result, based on my understanding of the QSA rules, they cannot go to another QSAC to retain their QSA status.
  • Finally, CSO has an opportunity to appeal the PCI SSC’s revocation of the QSAC and PA-QSAC status.  However, as of this writing, I have not seen anything in the press that would indicate that an appeal has been requested.

It will be interesting to see if CSO appeals this decision or just accepts the Council’s ruling.


A Carrot for Chip and PIN

On August 9, 2011, Visa USA announced an interesting program to give merchants a carrot to drive them to adopt dual-interface chip technology terminals that will accept EMV (aka Chip and PIN) as well as mobile payments using near field communication (NFC) also known as contactless cards and devices that can transmit card information via NFC.

The carrot Visa USA is offering merchants is a waiver on annual PCI compliance if merchants implement dual-interface chip technology terminals.  The criteria merchants must meet in order to obtain the waiver is:

  • At least 75% of the merchant’s transactions must originate from dual interface EMV chip-enabled terminals;
  • The merchant validated their compliance with the PCI DSS within the last 12 months with the merchant’s acquiring bank or the merchant filed a defined remediation plan with the merchant’s acquiring bank;
  • The merchant must have confirmed that they do not store sensitive information (i.e., track data, PIN, CVV) after completion of any transaction; and
  • Not involved in a breach situation.

The first requirement certainly drives the swap out of old terminals.  However, until banks start issuing the EMV and/or contactless cards in bulk, the investment by merchants in the dual-interface chip technology terminals is not going to happen.  What I am sure Visa USA is hoping is to get a large merchant like Wal-Mart, Best Buy or Target to buy into the program and therefore drive the issuers and banks to get on board.  Without a big box merchant, this program is pretty much dead on arrival.

The next two points are pretty much the same thing.  In order to be compliant with the PCI DSS, a merchant must prove that it is not storing sensitive credit card information.  The only reason I can see for the third point is, I am sure, to cover the “defined remediation plan” of the second point in the event that the gap found was related to storage of sensitive information.

The fourth and final point just makes complete sense.  If a merchant has been breached, they must have shown that they are PCI compliant before being allowed to be waived from a PCI assessment.

Is it a good idea to waive the annual PCI assessment for merchants all in the name of getting them to adopt a new technology? Particularly technologies that do not entirely solve the fraud issue with credit cards.  Yes, you heard me right.  EMV and contactless technologies do not entirely solve the fraud problem.  While they minimize fraud in the case of card present transactions, they do not even address fraud in card not present transactions.  And it is in card not present transactions where fraud is most prevalent.

So why the push for EMV and contactless cards?  That is a good question.  The proponents of EMV will tell you it is to curb fraudulent purchases.  However according the latest information I could find, while EMV is expected to drop card present fraud by 35% this year in Canada (the first full year they have EMV); card not present fraud is continuing to go up.  Based on statistics from a variety of sources, card not present fraud ranges anywhere from 40% to more than 60% of the total card fraud committed.

So, if EMV and contactless do little or nothing for the majority of fraud being committed, why the push for them?  That is a really good question.  And to tell you the truth, I have no idea why Visa USA is pushing this other than to make things consistent worldwide.  And from a standpoint of curtailing card present fraud, at less than 5% in 2009 (the last year statistics are available); there is certainly no ROI for EMV.  This is why EMV has not been rolled out in the US.  There is no payback if banks and merchants invest in EMV.

But then you have contactless cards.  Contactless cards rely on near field communications (NFC).  NFC is made possible by radio frequency identification (RFID).  Like the magnetic stripe, the RFID in a contactless card only has the PIN block encrypted.  Numerous proofs of concept attacks have been documented against these contactless cards.  The bad news for cardholders is that unlike EMV and regular credit cards, a contactless card can be skimmed without their knowledge or even suspicion.  The only way the consumer knows their contactless card has been skimmed is when they get their statement and see the fraudulent charges.

But the really stupid thing about EMV and contactless cards is that until every merchant has the ability to process them, they will continue to have to have a magnetic stripe.  This is particularly true for automated teller machines (ATM).  Even in Europe where EMV is the only type of card available, ATMs still require a magnetic stripe.  This would hold true for the US as well since even the major banks cannot afford to change out the card readers in all of their ATMs to support EMV and contactless.  As a result, any transition to these new cards will be a very long time coming.

That is not to say that EMV or even contactless could not take a significant bite out of card not present fraud.  While the hardware for the cards exists for PCs, the problem is that such a solution would require a standard application program interface (API) which the card brands, banks, payment processors and merchants have done nothing to create.  Over the years there have been a number solutions proposed by banks and card brands, but nothing that was adopted by everyone.  As a result, instead of fixing the problem, everyone just accepts it.

The bottom line appears to be that Visa USA is pushing high technology as a solution for card present fraud that just does not address the real problem.  However, I guess it is better to appear like you are doing something rather than not doing anything.

Relevant reading:

Chip And PIN

The Chip And PIN Debate – Part 1

 PCI SSC Nixes PA-DSS Certification For Mobile Payments Applications For A While



Like encryption, tokenization seems to have a mystic quality surrounding it.  And like end-to-end encryption, tokenization is seen by merchants as a way to avoid being bothered by that pesky PCI compliance process.  However, even with tokenization, merchants still have to comply with certain parts of the PCI DSS.

Before we discuss the risks and compliance requirements, let me explain tokenization.  In a nutshell, tokenization is the process of taking sensitive data as input and returning a “token” that represents that sensitive data as output.  The token typically has no relationship with the sensitive data it replaces and can be shorter or longer than the original sensitive data.  The token is typically made up of a variety of upper- and lower-case alphabetic, numeric and special characters depending on the algorithm used.  An important thing to remember is that tokenization does not imply encryption.  However, encryption may be used for tokenization as can one-way hashing.  When encryption is used as a way to tokenize sensitive information, the system receiving the token never has the capability to decrypt the token.

The way tokenization works for credit card processing is that the merchant’s point of sale (POS) system takes the cardholder data, either from a card swipe or manually input, and passes it to the credit card networks for transaction authorization.  Once the transaction is authorized, a 16 character token is generated by the processor and is passed back to the merchant’s POS where the token can be stored in place of the PAN.  This means that for credit card processing applications, the token is 16 characters long.  In addition, the token can contain the last four digits of the PAN for transaction reference.  The original cardholder data, i.e., cardholder name, PAN and expiration date is stored on the processor’s system for reference.

Note that in my example above I used POS as the system accepting the token.  There is no credit card terminal involved.  It is not that tokenization does not work with a credit card terminal, it is just that tokenization best pays for itself when used with an application that stores sensitive information and the end user does not want to store that sensitive information.  Since most credit card terminals are not configured for storing the PAN after authorization, there really is no point in using tokenization.

One feature that tokenization can provide is the ability to process recurring transactions.  In a recurring transaction scenario, the processor provides a mapping capability between tokens and the original cardholder data.  On a recurring transaction, the merchant passes the token back to the processor and the processor looks up the token and then generates a transaction based on the cardholder data associated with the token.

Depending on the tokenization method, another potential feature is the ability to analyze card usage.  In some tokenization solutions, a given PAN will always produce the same token value.  As a result, not only is the PAN protected, but it can still be used for analysis purposes such as fraud analysis and loyalty programs.

As with any technology there are risks associated with tokenization.  As we saw with end-to-end encryption, the endpoints in the tokenization process are at risk.  Because there has to be a way to get the cardholder data into the process, the merchant’s POS is the most likely point to attack.  The problem with POS systems is that they can typically provide a “target rich” environment to be leveraged either from their operating system or their applications.  While the PCI DSS has requirements to address these potential targets, ensuring security across the full range of targets requires a level of diligence that most merchants just cannot provide on a consistent basis.

Another threat shared with end-to-end encryption is the tampering of software used to process transactions.  While the PA-DSS certifies that an application properly processing and storing cardholder data, it has limited applicability as to whether an application is surreptitiously storing or transmitting cardholder data prior to starting the tokenization process.  As a result, it is relatively simple to introduce tampered with software that could gather cardholder data without the merchant knowing.

To mitigate the risks of tokenization, merchants should consider the following actions.

  • Purchase your POS software from a reputable vendor.  This is not a perfect solution to the problem, but doing this should be better than buying it off of eBay or downloading a free open source solution.  Yes, you save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised?  Probably not.
  • Ask your supplier of POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank.  Ask them to provide those procedures in writing and review them to ensure they appear adequate.
  • Use serialized tamperproof tape on the seams and doors of your POS workstations.  Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with.  If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
  • If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
  • Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
  • Patch your POS workstations and application as soon as possible to minimize their susceptibility to attack or compromise.
  • If the vendor of the POS solution will perform updates, make sure that you or someone in your organization schedules the updates.  If anyone shows up at a location to “update” your POS and it was not scheduled by your organization, contact law enforcement.
  • If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process.  At the end of the update process, the person should terminate the remote session of the vendor.

At the end of the day, tokenization is not a bad solution for those environments where investing in all new POS is not an option or where the merchant might still want the ability to do PAN analysis.  However, tokenization has risks just like any other solution.  Granted, those risks might be fewer, but there are still risks.  And it is important for merchants considering tokenization to understand those risks before blinding accepting them.

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

August 2011