Interesting Announcements From The PCI SSC

For those of you that are not QSAs, the PCI SSC over the last year has tried to keep QSAs in the loop by issuing a monthly Assessor Update newsletter via email.  These usually are not noteworthy, but the November 2010 issue contains a number of items that need to be shared just in case you miss your edition or you are not a QSA.

PCI DSS Timeline Clarification

The Council apparently got the message that they did not communicate the sunset date for the PCI DSS v1.2.1 and the start date for PCI DSS v2.0 very well.  As a result, they issued a clarification in the November 2010 newsletter.  To quote the Council:

“Entities needing to comply with the PCI DSS are strongly encouraged to begin using the new standard immediately. However, version 1.2.1 will remain effective until December 31st, 2011 to allow everyone time to adopt any changes they may need to in order to maintain their PCI DSS compliance. This means that organizations assessing and reporting compliance during 2011 may validate to either version 1.2.1 or 2.0. However, the Council urges all organizations to complete their transition to the new standard as quickly as possible, especially where any new controls may enhance the protection of cardholder data.”

Since QSAs will not have the scoring template until sometime in January 2011, it makes planning and executing any assessments difficult until the scoring template is issued.  As a result, the earliest I can see any v2.0 assessments getting started is March 2011.

PCI DSS and PA-DSS v2.0 Scoring Templates

And speaking of those scoring templates, the scoring templates for v2.0 of the PCI DSS and PA-DSS should be published sometime in January 2011.  It would be nice to have these a bit earlier, but better late than never.

Expiration Of PABP v1.4 Extended 90 Days

The PABP v1.4 standard that was expected to expire tomorrow, December 2, 2010, has been extended to March 2, 2011.  To quote the Council:

“This updated deadline recognizes the challenges many merchants and Payment Application end users have in implementing system changes over the busy holiday period, and allows the Payment Application vendor community to consider submitting new versions of their products for assessment against the new PA-DSS 2.0 standard.

The Council is committed to reviewing all submissions for the updated versions of expiring PABP v1.4 applications, and this new March 2nd 2011 deadline will allow the review process to be completed before previous versions of these applications expire.  This extension will also provide more time for PA-QSAs to complete reviews of those Payment Applications that are currently in process.  Finally, this extension will allow Payment Application vendors, should they choose to hold off on assessment of expiring Payment Applications and instead submit (after January 1st, 2011) their Payment Applications for assessment against the new PA-DSS v2.0 standard.”

ASV Sampling And Scanning Do Not Mix

While sampling of devices is allowed under the PCI DSS, it is not allowed for ASV scans.  To quote the Council:

“Within a given quarter, all Internet accessible systems must pass an ASV scan. It is not necessary that they all be scanned at the same time, but they all must be scanned quarterly.”

Apparently, some ASVs were only scanning a sampling of PCI in-scope devices each quarter.  I am sure this will lead to consolidation of a lot of organization’s external network presence.

2011 PCI SSC Training Schedule

The training schedule for next year should be posted to the PCI SSC’s Web site by mid-December.

Telecom Private Circuit FAQ Issued

See the end of my post on MPLS for the text of the FAQ.

Advertisement

Why The PCI Standards Exist

After another spate of articles and speeches about the PCI DSS and why it is worthless, I thought it might be a good idea to explain why the PCI standards came to exist.

In 1999, Visa USA began to work on what became the Customer Information Security Program or CISP.  The first official version of the CISP was issued in the summer of 2003 with Visa asking select merchants to comply with the CISP as soon as they could.  The original impetus for the CISP was a response to increasing chargebacks that were the result of the fraudulent use of credit card accounts.  An analysis of these chargebacks had started to paint a picture of merchant employees that were increasingly using their access to point of sale (POS) and accounting systems to obtain credit card numbers and then using those numbers to commit fraud.

As development on the CISP progressed, Visa USA also started to see increasing instances where an e-Commerce site had been compromised and the credit card information stored on the site had been taken by an attacker and then was fraudulently used.  The reason these compromises had resulted in cardholder data being exposed was that application developers had used the same software design models for e-Commerce as those that were used by traditional POS.  This resulted in cardholder data being stored in databases that faced the Internet.

A year or so after the start of Visa USA’s efforts, MasterCard International began development of the Site Data Protection (SDP) standard.  Unlike the CISP, the SDP focused specifically on the security of e-Commerce sites.  MasterCard had monitored the rising fraud rate related to the compromising of e-Commerce sites.  Like Visa USA’s analysis, MasterCard’s analysis of the problem pointed to the fact that most e-Commerce sites were storing cardholder data in databases that faced the Internet and were not very well protected from compromise.  As a result, MasterCard approached the problem with the SDP which specified a basic level of information and network security for e-Commerce Web sites.

As work progressed on the CISP and further statistics on security issues were gathered, Visa USA began to recognize that the on-line payment applications themselves were the biggest problem related to the compromising of cardholder data.  As a result, Visa USA developed the Payment Application Best Practices (PABP) standard.  The PABP was published in late 2004 with Visa USA encouraging software vendors to use it as a benchmark for securing their software.

It has been suggested that the PCI standards were only developed to minimize the losses to the card brands and banks and do nothing for merchants.  However, the PCI standards were meant to protect everyone in the transaction process.  When a breach occurs, the first thing people remember is the name of the card brand(s) involved, the second name is likely the merchant or service provider and the third name is the franchisee if that is the case.  The card brands, service providers and franchisers discovered that their reputations were highly at risk, even though it was typically the franchisee merchant that actually created the problem.  Regardless of who caused the breach, the card brands further discovered that what people really remembered from breaches were the card brands’ names and everything else was forgotten.  As a result, the card brands became determined to protect their brand names and reputations.

There was another recent suggestion that the PCI DSS was not needed because market forces would resolve the security issues inherent in the conducting of credit card transactions.  The first problem with that idea is that most merchants and service providers are unconvinced that they are responsible for securing cardholder data, even after they might have suffered a breach.  They believe that it is the card brands’ problem to secure cardholder data because the card brands are the ones that generate the cards.  Unfortunately, the security of cardholder data is mostly outside of the control of the card brands, therefore the merchants and service providers need to be responsible for securing cardholder data as well.  The second problem with that idea is that for every security “expert”, there are a corresponding number of security baselines.  No one agrees on security, because everyone’s view is from their own perspective and the threats that they see or perceive.  As a result, some organizations have very strong and strict security (e.g., banks for example), while others have only marginal security.  The problem with this approach is that security is only as good as the weakest link in the chain.  So those organizations that have weak security practices become targets against the entire process chain.  As a result, in our interconnected world, that puts those organizations with strong security at risk if they are partners to those organizations that have weak security.  As a result, the card brands recognized that a single standard baseline was needed just to provide a basis for a consistent foundation on which to build additional security.

So, that is how we got where we are today.  Hopefully with this perspective you can now understand why the standards exist and their use in providing basic, essential security for cardholder data.

Extremely Mobile Payment Processing

In a previous post I discussed mobile computing and PCI compliance.  In the last couple of weeks I have been questioned about using mobile devices such as smartphones and Wi-Fi enabled PDAs as payment terminals and I thought this particular incarnation of mobile computing deserved an in-depth look.

Pay attention to that Apple iPhone advertisement.  If you notice in one of their advertisements they show a person processing a credit card payment on their iPhone.  As Apple likes to say, “There’s an app for that.”  However, it is not just Apple that has a payment application for a mobile device; there are also payment processing applications for Windows Mobile environments.  There are also proprietary solutions from VeriFone and the like.  Some of these applications are PABP and/or PA-DSS certified.  Devices from VeriFone and the like are PCI PTS certified, but the iPhone and other cellular phones as well as PDAs are not PCI PTS certified devices.

So when the pizza delivery person shows up at your door and wants to swipe your credit card through their mobile device, how do you know that it is safe?  You likely will not know.

The security surrounding the telecommunications used by these devices is the easiest thing to discuss.  All of the devices I have been able to examine use telecommunications methods that are encrypted either by SSL v3 or TLS.  The cellular network and Wi-Fi are just used as the conduit and are not relied upon to provide any security.

Do not assume that VeriFone and the like are meeting all of the PCI standards.  While their mobile payment terminals are PCI PTS certified, the application software in those devices is not PA-DSS certified.  I pointed to the flaws in these devices in a previous post.

But there are bigger problems lurking with the iPhone.  Ask any computer forensic examiner about the iPhone and they will talk at length about the fact that the iPhone has a number of “features” that make security and privacy things of the past.  From a PCI compliance perspective, some of the more problematic issues are as follows.

• Deleted information does not physically get deleted.  In some cases, deleted data can remain on an iPhone for up to six months or even more depending on use.
• The iPhone has a built-in keyboard logger, so anything typed into it is recorded.
• While it is not certain that card swipes would be retained on the iPhone, given all of the other information it retains, it is highly likely that such information would also be retained.

As a result, using the iPhone as a payment processing platform is probably not a good idea until it is certified.

So what, if anything, are the PCI SSC and/or the card brands doing about this situation?  As much as they can, given that these solutions are popping up faster than they can identify them.  The problem is that the developers of these applications are usually unaware that they are required to comply with various PCI standards.  And since the developer is responsible for certifying their solution unless they get ‘ratted out’, the solution will not get certified.  So it is up to the application developer and the merchants to ensure that an application is properly certified.  If that is not worrisome enough, the cost involved in certifying such an application would likely raise the cost of that solution to a point where it would not be economical to the merchant or salesperson.

Louisiana Restaurants Follow Heartland’s Example

If you missed it, a half dozen restaurant companies based in Louisiana have sued their point of sale (POS) vendor and the POS vendor’s reseller over a security breach that was identified in 2008.  There are a number of troubling facts involved in this complaint that I think deserve to be discussed.  Unfortunately, these merchants are taking a chapter out of the Heartland breach playbook by saying it is entirely someone else’s fault.

My first problem with this case is the spelling errors and misrepresentations of some of the facts.  It is tough to take a lawsuit seriously when the law firm involved did not take the time to spell check and proof what they were writing or ensure that the historical facts are accurate.  With that said, let us take a look at this wonderful legal mess.

From the filing we get the start of their terrible tale of software gone awry.

“Notably, Visa identified [vendor]’s POS software as a payment application that stored prohibited data, such as full magnetic stripe data (including card verification and PIN data), after a transaction authorization was completed.

Around the same time, [vendor] was advertising that the [vendor]’s POS system was enhanced to comply with the PCI Data Security standards.

Plaintiffs all purchased the [vendor]’s POS systems from [reseller].”

Later in the complaint, they state:

“Plaintiffs would not have purchased the [vendor]’s POS systems had they known of the security defects contained in the software.”

They already knew that the software was not compliant and they admit it in the first part of the complaint.  Visa is the certification body and had listed the software from the vendor as non-compliant.  What more could you want?  Yet they still purchased the software.  This is why you conduct a formal software selection so as to avoid these types of problems.  Buying software is a sophisticated process requiring research and documentation of one’s requirements and matching those requirements to the various vendor offerings.  First key requirement in this case should have been is the software PCI compliant.  If not, it is not included in the selection process.  This just shows terrible due diligence and lousy business acumen on the merchants’ part.  Strike one against the merchants.

But it just gets better.  In 2008, these restaurants all get contacted by their local law enforcement agencies and are told that they are the source of a credit card compromise.

“Thereafter, Plaintiffs undertook their own research to determine whether their systems had been compromised.

Plaintiffs ultimately learned that keyloggers had been installed on their POS stations.”

As they say down South, “This dog just don’t hunt” and it does not hunt for a number of reasons.

First, after they do not do proper due diligence, I am supposed to suspend belief and believe that these merchants had the technological prowess to figure out that a keylogger had been installed on their systems?  The reason I have a problem with this is that later on in the filing it states that they hired outside consultants to remove the keylogger software.  Therefore I have to assume since it is not explicitly stated that no outside assistance was obtained in identifying the keylogger.  Bottom line – the merchants violated a key incident response principle by not getting a forensic examiner involved immediately.  Strike two against the merchants.

However, this points out another troubling issue.  Does this sound like a group of organizations that have an incident response plan in place as required by the PCI DSS?  Based on the complaint, it sure does not read that way.  So, guess who is not PCI compliant?  Strike three against the merchants.  Unlike baseball, PCI players are not out after three strikes, the strikes just continue to accumulate.

Let us assume that the vendor’s software these merchants installed was truly PABP or PA-DSS compliant and the keylogger claim is also accurate.  If the application stores cardholder data encrypted, then the only way that the keylogger could have allowed anyone access to the data is that one or more of the accounts had access to the data encryption keys.  There are a couple of things that could have caused this; (1) the reseller used the same administrative password for all systems they install, (2) the application is designed such that administrators have access to the encryption keys, and/or (3) the merchants assigned a number of users as administrators that had access to the encryption keys.  Everyone could have fault here and without extra information there is no way to know who is at fault.

Another thing that troubles me is the fact that every plaintiff had a keylogger on their POS system and I am assuming it was the same keylogger since the complaint does not say differently.  It just seems a little too coincidental that they all were attacked the same way.  If I were a betting man, I would say this is an inside job because the facts all point that direction as well as the statistics say that it is the most likely scenario.  Insider meaning someone that had knowledge that all the systems were configured the same.

Finally, where is law enforcement in all of this?  All of these systems are technically a crime scene, yet nowhere does the complaint mention anything about law enforcement seizing the compromised systems for a forensic examination.  You would have expected law enforcement to have seized these systems and the reseller having to supply new systems to replace them.  Apparently that never happened.  Strike one against the law enforcement agencies for not treating this for what it was, a crime.

As if it is not bad enough, things get worse.  The reseller was unable to remove the keylogger, so the merchants had to go out and get help.

“These consultants discovered that [reseller]’s standard practices violated numerous provisions of the PCI Data Security Standards.

In addition to incurring substantial costs for additional technicians, consultants, software, and network connections, news of the credit card number thefts were reported by local media, which resulted in loss of business to Plaintiffs.”

Well, here is a shock, the ‘hired guns’ find that the reseller wasn’t complying with PCI requirements.  This confirms an earlier strike against the reseller, so they get another strike as well for this lapse.

Here is something that any reseller or vendor that is providing managed services should worry about.

“Defendants failed to notify Plaintiffs that the [vendor]’s system was breached”

I am not sure how the software vendor was to have known this.  But, if the reseller was also providing managed security and/or network monitoring services to the merchants, then they are really on the hook for this one.  However, if the reseller was not providing any managed services, I would seriously question how a breach would be known by the reseller.

Finally, the complaint states:

“After the problems were identified and corrected, Plaintiffs were fined by credit card companies for failing to comply with the PCI Data Security Standards and/or their Payment Application Best Practices (PABP).”

At a minimum, these merchants were likely covered by SAQ C.  Requirement 12.5.3 in SAQ C very clearly states that the merchant is required to have developed a documented incident response plan.  As a result, these merchants were also likely not compliant with the PCI DSS.

The complaint also seems to indicate that the vendor’s software solution was not really PABP compliant.  This is another strike against the merchant for their lack of due diligence.  It may also be a strike against the reseller and/or vendor if they misrepresented the PCI compliance of the software.

In the end, the merchant wants the reseller and the vendor to take all of the blame for their poor decision making process.  If that sounds familiar, it is.  This is exactly the same rationale that Robert Carr used to justify the Heartland breach.  It was everyone else’s fault.  As with the Heartland incident, there is more than enough culpability for everyone involved.  But I leave the bulk of the blame to the merchants who created their own problem in the first place.

So, what are the lessons learned from all of this?

• Conduct a formal software selection regardless of how ‘simple’ you may think the solution and process may be.  Formally document and prioritize your requirements.  If there are any ‘drop dead’ requirements, make sure that you use those to qualify all of your candidates before including them in your process.  Since most organizations do not regularly conduct formal software selections, this is a good project for an outside consultant who does such projects regularly.  Yes, it costs real money to hire an expert, but it pays dividends down the road by keeping you from making poor decisions that you will regret later.
• Never take anyone’s word when dealing with compliance.  If the certification body’s documentation indicates that a given product or service is not compliant, then it is not compliant.  If you really must, get the vendor to provide you with a copy of their documentation that they have filed with the certification body and when it was filed.  Then contact the certification body and confirm that the documentation was received from the vendor and when the certification body will likely act.  If the granting of certification is too far out or you cannot go through this process, then the certification does not exist.
• Make sure your reseller is complying with all relevant requirements when installing and maintaining your hardware and software.  This involves not only getting it in your contract with the reseller, but also setting up milestones that require your review and approval before the reseller goes to the next step.
• Make sure you have an incident response plan.  It seems like ‘make do’ work until you really need it.  Incident response plans are very much like disaster recovery and business continuity plans, they are insurance policies against bad decision making during a crisis.
• Obtain experienced assistance when you need it.  There is a lot of truth in the old adages, “You can pay me now or pay me later” and “Penny wise but pound foolish.”  I am sure these merchants thought that they were saving themselves a ton of money by skipping a formal software selection process.  But in the end, it came back in spades when they suffered the breach and the resulting drop in business.

We Are In This Together

I am starting to hear a troubling rationale regarding PCI compliance.  It typically is expressed as a reluctance to comply with the complete PCI standards because the organization does not store cardholder data.  You hear people questioning why they need to have anti-virus, log analysis, file monitoring and other security measures in place if they are not storing cardholder data.

Well, get a clue, your organization is just one of many in the systems that handle cardholder data.  Your organization is just one part of the overall cardholder data flow.  Cardholder data flows from the merchant to one or more gateways or processors to an acquirer and back.  Each one of these entities is dependent on the security posture of the other to ensure that cardholder data is protected.  If you are shortcutting security at your point in the process, you are creating a gap in everyone’s security.

If your organization is one of the lucky ones to have gotten cardholder data off of all of your systems, you still process and/or transmit cardholder data.  People sometimes forget that the PCI standards are about the processing, storage or transmission of cardholder data.  Just because you no longer store cardholder data, you still need to be concerned about securing the processing and transmission of cardholder data.

Securing the processing of cardholder data is typically the easier of the two to control.  All you have to do is control the access to the device and make sure that users cannot access the memory of the device.  However, with today’s development environments, security surrounding the processing of cardholder data is not as simple as it seems.  Most developers have no idea as to how their programs physically work when it comes to memory management.  As a result, we are seeing more and more instances of cardholder data being stored in the memory of all sorts of devices.  In the best cases, the cardholder data in memory is cleared once the transaction has been approved or declined.  However, in a lot of cases, the device memory contains every transaction that has been processed since the last run of end-of-day or similar process.  And powering off a device is no guarantee that memory is purged.  As a result, just because you only process cardholder data does not mean you are safe.

Then there is the more obvious security related to the transmission of cardholder data.  End-to-end encryption is in the news ever since Robert Carr of Heartland Payment Systems made it all the rage.  However, security of the transmission of cardholder data is also easier said than done.  One of the biggest obstacles can be the processors, gateways and acquirers themselves.  A lot of these organizations do not even support the secure transmission of cardholder data.  While this situation is getting better every day, it still surprises me how many of these organizations are still transmitting cardholder data in an insecure manner.  However, even with end-to-end encryption, there are still ways to compromise cardholder data.  Yes, it is more difficult, but it is not impossible.

All of this discussion of securing memory and communications is moot if the PCI standards are not completely followed.  If anyone is able to compromise the data flow at any point in the line, the flow is compromised.  And once compromised, the data is for the taking.  Therefore it is imperative that everyone in the data flow keep their guard up and ensure that their security measures are sufficient to protect the data flow.  That means following the PCI standards to ensure security.

The other part of this troubling situation is that when all cardholder data gets removed from the merchant systems, it will be the processors, gateways and acquirers that will become the targets.  Attackers will do whatever it takes to get into them for the data they hold.  If organizations that connect to these entities are not doing everything they need to secure their environments, they will be used as the way into the processors, gateways and acquirers.

That is why everyone needs to stay on top of their game even when cardholder data is no longer stored.

PA-DSS Certification Means Nothing?

A couple of weeks ago we had a conference call with our PCI SSC QA team.  During that call, one of the areas we discussed was the relevance of PABP or PA-DSS certification on the PCI DSS Security Assessment Procedures (SAP) or the Self-Assessment Questionnaires (SAQ).  At the end of the discussion, essentially what we were told was that the PABP and PA-DSS were not relevant to a merchant’s compliance with the PCI DSS.

Based on this definition, I can understand why software vendors are so anti-PCI compliance.  If the PABP or PA-DSS does nothing to help customers achieve PCI compliance, then why pay to have your solutions certified?  From a merchant’s perspective, why buy a PABP or PA-DSS certified application if it is meaningless to your PCI compliance under the PCI DSS?  We were even told in our QSA recertification training in the spring that the relevance of PABP and PA-DSS was really nothing.  Trust me, there is nothing worse than telling a client that, even though their application is PABP or PA-DSs certified, you still have to cover all of that ground all over.  In my mind, what this implies is that PA-QSAs are not to be trusted.  This is a situation similar to relying on other QSA’s work.

Yes, I know that Visa mandates application certification for purchased solutions.  However, if there is no business benefit other than making Visa happy, why bother?  It is positions like this that give critics the material to successfully argue the short sidedness and irrelevance of the PCI standards.

I do agree that you cannot use PABP or PA-DSS compliance to just brush aside all of the PCI DSS.  However, there are some obvious areas where such a PABP or PA-DSS certification should be a valid control as long as the application is implemented per the vendor’s Implementation Guide which must explain how to maintain PCI compliance.

For instance, if you have an application that is PABP or PA-DSS certified, what is the point of covering requirements 3.2, 3.3 and 3.4?  In my opinion, if the application is implemented properly, this section should be Not Applicable because the application is PABP or PA-DSS compliant.  However, based on our training, marking this not applicable is not allowed.

Another set of meaningless requirements when dealing with a certified application are 6.3 – 6.5.  As long as the client is not modifying the application, these are pointless.  The PABP and PA-DSS cover these for the software publisher, so they should be not applicable as well.  However, as a QSA you are still required to prove that you did the proper assessment of these points regardless.

Nine times out of ten, the vendor is really irritated (this is being kind) when you ask them to explain how they meet these requirements.  And rightly so.  They have spent tens of thousands of dollars per application to have them assessed as PABP and/or PA-DSS compliant.  And now you have an army of QSAs contacting them to cover the same ground as the PA-QSA covered.

At some point, the PCI SSC needs to get a clue about what is going on out in the field.  I know that this topic has been brought up on a number of occasions, but there just does not seem to be any interest in dealing with the issue.  Until merchants, service providers and software vendors start to see that the PCI standards have a real business benefit, we are going to fight our way tooth and nail to a secure card processing environment.