The Threat Landscape Has Changed

In an earlier post, I discussed how the PCI DSS changes based on changes in the threat landscape.  Attention, Robert Carr at Heartland Payment Systems and anyone else processing, storing or transmitting cardholder data, here is a change in the threat landscape that will radically affect the PCI security standards, most definitely the PA-DSS, but also the PCI DSS.

Verizon Business Services recently announced that they are seeing a rise in RAM scraping attacks.  RAM scraping is an attack that utilizes a program to go through the memory of a device looking for certain information.  RAM scraping has been around for quite a while, but only recently was this technique adapted for finding cardholder data.  With the push for end-to-end encryption, Verizon Business Services predicts that RAM scraping attacks will continue to rise.

Now if you are Robert Carr, you are likely questioning how RAM scraping attacks can gain access to cardholder data when end-to-end encryption has been implemented.  After all, you have been told that end-to-end encryption is the answer to protecting cardholder data.  Yes, once the data is encrypted, as long as strong keys and proper key management practices have been implemented and are followed, the data is protected.  However, the data is not protected at the end points where the data is encrypted and decrypted.  It is at these endpoints where RAM scraping targets end-to-end encryption.

At some point, the data must be in a format that can be processed and that is what the people that develop these RAM scrapers rely on.  But the cardholder data is only in memory for such a short time, possibly only a millisecond.  Do not be so sure.  Unfortunately, with the advent of high-level languages and cheap memory, memory management is not as well managed as you might think.  We have seen instances of cardholder data being stored in the memory of card terminals and PCs for hours, days and in some very rare cases, forever.  As a result, if you can gain access to the memory of these devices, you can hit the mother-lode in cardholder data.

Now before you go off in a panic, the PCI DSS does have some protections that are already provided.

• Requirement 1 – Firewalls.  There are a number of requirements in this section regarding the regular review of firewall rules, control of network traffic and other topics.  However, the purpose of these requirements is to respond to the changing threat environment.  In addition, firewalls generate alerts and log data, so these should be regularly reviewed to make sure that a RAM scraper has not been introduced into the environment.
• Requirement 3.5 – Encryption Key Management.  As long as you follow the recommendations in this set of requirements, your encryption keys should be safe.
• Requirement 5 – Anti-Virus.  Most of these RAM scrapers are installed through some sort of attack that uses virus and/or malware techniques.  If your anti-virus is up to date and it protects against malware, you will likely be notified of such an instance.  The attack is likely not going to be direct, so you need to make sure that all systems that interact with your cardholder data environment need to be monitored to ensure that a RAM scraping payload is not delivered anywhere in your network.  The key is monitoring.  If you are not actively monitoring attacks, you will likely miss the introduction of the RAM scraper.
• Requirement 10 – Log Analysis.  If you are properly reviewing your logs, the alerts from your anti-virus and critical file monitoring should be contained in your log data.  The key is that you are conducting log reviews at least daily, if not more often.  If you have a centralized log collection system, I would recommend that you create queries that use criteria to meet various PCI DSS requirements.
• Requirement 11.5 – Critical File Monitoring.  RAM scrapers are executable files.  If you have configured your critical file monitoring correctly, this new executable will trigger an alert.  However, not all end points can be monitored this way, so you may have to find another approach to protect those devices.  Again, monitoring is the key.

If you are religiously following these points, you should be addressing this new threat as best as you can.

As I have constantly stated, security is not perfect.  So, just because you are following the PCI DSS does not mean that you will not have an incident.  It only means that the impact of an incident will be minimized.

Disaster Recovery Sites and PCI

Here is something that troubles me.  Mainly because I think a lot of QSAs are not looking at cold and warm disaster recovery sites since they are technically out of scope in the PCI DSS if they do not process, store or transmit cardholder data.  However, this is something that needs to be looked at because under the PCI DSS, a disaster recovery site is in-scope once it is processing, storing or transmitting cardholder data.

First, let us get the terminology straight as to what we are talking about.  A disaster recovery ‘cold site’ is defined as a site that has physical and environmental controls, but does not contain any equipment.  Essentially, it is an empty data center.  It may have racks installed with electrical connections, but the racks are empty or only contain enough infrastructure to allow for basic connectivity from the racks to the telecommunications point-of-presence (POP).  An organization may have backup circuits installed to this facility, but they too are not in use.  As a result, a cold site is not in-scope because it does not process, store or transmit cardholder data.

At the other end of the spectrum, a disaster recovery ‘hot site’ is ready to go at a moment’s notice.  Applications and data are replicas of what is running in the production data center.  Should a failure occur at the production data center, the hot site will immediately step in and take over usually without users knowing that a failure has occurred.  Obviously, a hot site is always in scope for PCI compliance as cardholder data is processed, stored or transmitted at the hot site just as it is at the production data center.

And in between cold and hot sits the disaster recovery ‘warm site’.  Warm sites have servers, data storage and infrastructure all ready to go, but the equipment is not running and no data is available.  It may or may not be a carbon copy of the production data center from an equipment standpoint, but it will have enough servers and infrastructure to be ready to process as quickly as possible.  The applications may or may not be already installed on the servers.  And data is usually expected to be restored from backup media.

Where things get messy is with just how much preparation is being done at the warm site.  Remember, disaster recovery sites are only in-scope if they process, store or transmit cardholder data.  And that is where some QSAs get in trouble; they neglect to ask the critical question of whether or not the warm site has cardholder data.  A lot of organizations are now replicating data between their production data center and their warm site.  It is cheaper, safer and faster to have a replica available than to try and recover data from backup media.  Particularly when you have invested in storage area network (SAN) farms at both locations.  SANs make the replication process easy and seamless with the only limitation being the time it takes to replicate over the connection between the two sites.

Regardless of what the PCI DSS states, I believe that all disaster recovery sites need to be assessed for PCI compliance regardless and here is why.  The PCI DSS states that disaster recovery sites are not in-scope unless they process, store or transmit cardholder data.  However, in the same breath, the PCI DSS states that once a disaster recovery site is activated, the site is in-scope and is required to comply with the PCI DSS requirements just as the production data center complied.  So, how does one know that their disaster recovery cold or warm site will comply with the PCI DSS if it is never assessed?  You do not know it will comply unless you assess it.  How is that for a Catch-22?  That is why I contend that all disaster recovery sites should be assessed whether they process, store or transmit cardholder data or not.

The bottom line here is that if you are not in compliance when you activate your disaster recovery site, you can be fined for non-compliance with the PCI DSS.  And if you think that you can get a ‘by’ on compliance by saying you were in the midst of recovering from a disaster, think again, particularly if a breach occurs during your recovery.  So, I highly recommend that all organizations make sure that their disaster recovery sites are and will be PCI compliant once they are active and that they are assessed by your QSA.

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.

Six Sigma, PCI And Security

First, this is not a security metrics article.  So, if you are looking for that sort of thing, this is not it.

Do you remember Six Sigma?  It has gone a bit underground, but is still big in manufacturing and distribution.  Six Sigma is defined as executing a given business process with only as much as 3.4 defects or errors per million executions of the process.  That is 99.99966% accuracy or higher.  I have stated in previous postings that security requires 100% compliance.  To come as close to 100% as possible, security is structured in layers (i.e., defense in depth) so that as long as each layer operates at Six Sigma levels or better and that those layers overlap, you should be able to achieve close to 100%.

One of the complaints you hear about the PCI standards is that a lot of it is focused on policies, standards and procedures and that documentation does not lead to security.  Six Sigma experts will point out that if you do not have formally documented policies, standards and procedures, there is no way to achieve the necessary levels of consistency to ensure your organization’s security.  Such documentation is the foundation on top of which you build everything else.  Without a solid foundation, Six Sigma cannot be achieved.

Then there is the training involved.  Six Sigma has taught organizations that training is another critical component if you expect to achieve it.  If you are not training your personnel in all of your policies, standards and procedures and the rationale of why those are important, your employees are just going to blow them off.  And if you are not training them regularly, then they will very quickly forget all about them.  These people are key to the success of your security program because, for the most part, they are the root cause of why security has failures.  Statistics point to the fact that at least 65% of all breaches were the result of human errors or other human causes.  If you are not addressing the human factor in your security program, then you are doomed to fail.

I like to use the airline industry as a prime example of how well documented policies, standards and procedures can make a significant difference.  Airlines have policies, standards and procedures for everything regarding the flying and maintenance of an airplane and they rigidly enforce them, they have to, to stay in business.  Over time, airlines found that human error was reason for most of the devastating crashes.  By instituting very rigid policies, standards and procedures, the airline industry was able to make air travel safer than driving your own car.  It is the same with security.  If you create a highly documented set of policies, standards and procedures just like the airlines and you rigidly enforce the following of that documentation, you likely reduce your risk of suffering a breach or other security incident almost down to zero.  I say almost, because there are people out there that, if they set their mind to breaching your security, they will do whatever it takes to get the job done, no matter what barriers you put in their way.

So what typically causes security failures?  There are a number of issues that lead to security failures, but these seem to be the most common.

• Someone cuts corners to get something done to meet a deadline.

• Someone disables a security measure or mis-configures it.

• Someone does not understand why a particular process is important and therefore just ignores it.

• Someone encounters an incident and does not know what to do, so they wing it.

The first three issues are all the result of limited or no training.  If people do not understand their role and the reason why their role is important, they will very easily regard their part as inconsequential and therefore not important.  And while you have defense in depth, if enough people take this attitude, the depth of your security does not matter.

This leads to the problem of keeping people engaged.  This is one of the biggest problems in security these days.  Do you realize that airports have been at the security advisory level of High since 2003?  That has been over six years.  Does anyone remember why or, for that matter, care?  No, because people are no longer engaged.  This problem is particularly true for people that monitor for security alerts.  A lot of the reason that security technology initiatives fail is not due to the technology, it is due to the fact that the technology was not tuned properly to weed out enough of the chaff so that the real alerts would shine through.  As a result, people start to ignore all the alerts because there are so many false positives to research before they get to the real issues .

The last bullet is a real sticky issue as it is exceptions to those well defined processes where every organization runs into trouble.  It is the lack of definitive procedures for handling every exception where organizations fall apart.  The rationale you hear for this time and again is, “we cannot anticipate every possible exception.”  While this statement is very true, you can have a group of very well trained personnel that can handle those exceptions on a case-by-case basis.  If this sounds familiar, it should.  This is exactly how help desks are structured.  For security, Level 1 researches basic security issues such as locked accounts, denied access requests, service failures and the like,  Level 2 researches items that Level 1 is unable to resolve or get answers as well as notifying users of new threats.  And those Level 3 people – they are the “propeller heads” that can do anything related to your security infrastructure.  Typically, Level 3 people are the ones that implement and maintain your security infrastructure.

At the end of the day, all of your security technology is only as protective as the people that interact with it.  A lot of organizations keep searching for technological solutions to solve all of their security problems.  Unfortunately, they miss the human part of the equation and the fact that it is the humans that are fallible and will be the most likely reason that all of their precious technology gets defeated.  So, get your documentation in order, train the staff until it hurts and enforce everything.

Framework Versus Standard

I think one of the biggest problems with the PCI DSS is that the PCI SSC chose to use the word ‘Standard’ in its name and proscribed that they are a standards setting body.  The word standard is defined by Merriam-Webster’s Dictionary as “something established by authority, custom, or general counsel as a model or example.”  Standards dictate what someone or something should do in a given situation.  Look at the IEEE for example.  They are a true standards setting body and the standards they issue are very proscriptive.  You are not to vary from the IEEE standard without becoming non-compliant.

When you look at the PCI DSS, it is more of a framework than a standard.  A Framework is defined as “a basic conceptual structure.”  Frameworks document boundaries as to what are acceptable for addressing particular problems but do not proscribe specific solutions.  In my opinion, the PCI DSS is more of a framework, not a standard.  I think that is why a lot of people and organizations struggle with complying with the PCI DSS.  If it were a true standard, then it would tell them exactly what and where to do everything.

That is the problem with security.  One size or solution does not fit all.  What works in one situation, may not work in another situation.  Even in the same organization, you can have different security solutions for the same problem.  Over time, while an original solution may be working fine, a newer solution will be implemented to resolve a similar situation because either the original solution is no longer available or it has changed and is no longer viable for the new requirement.

So let us stop getting hung up on the word ‘standard’ and move on.  The PCI DSS is not a standard it is a framework. A framework that is a baseline of what, at a minimum, is required to protect cardholder data.  If you can execute the framework on a consistent basis, then you will be ahead of the game.  If you cannot execute on a consistent basis, then you should do everything you can to not store cardholder data.

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.

PCI Compliance and Franchising

There was post recently on the SPSP Forum regarding the lack of information on franchise operations and PCI compliance.  Since I have been searching for a topic to write on, I thought I would take up this topic.

The PCI DSS has only one reference to franchises and that is on page 7.  The reference on page 7 is only in regards to sampling.  During our first year of QSA training, we were told that PCI compliance in a franchise environment is controlled by the operational relationship between the franchiser (the organization that licenses the concept) and the franchisee (the organization that executes the retail concept).  Franchisees typically maintain their own merchant accounts and have their own contracts with an acquiring bank.  For PCI compliance purposes, most franchisees are independent from their franchiser and therefore, the franchisee is responsible for their PCI compliance and any document filing.

At their simplest, franchisees use “knuckle busters” and stand-alone terminals.  In these instances, the franchisee can fill out and file a self-assessment questionnaire (SAQ) B.  Other franchisees, such as those in the fast food industry have purchased un-customized integrated point of sale (POS) with a network at the restaurant.  These sorts of installations typically meet the requirements for SAQ C.

However, thanks to technology and integration, the PCI compliance of the franchiser and franchisee can blur.  The best example of technology creating a PCI compliance nightmare for a franchiser is Speedpass from Exxon/Mobil.  Speedpass is a great customer convenience and probably one of the more innovative uses of RFID technology.  The customer registers one or more credit cards at the Exxon/Mobil Web site and is mailed a Speedpass RFID fob.  At the service station, the customer merely waves the Speedpass RFID in proximity to the Speedpass logo on the gas pump and they are validated and pay without a credit card ever being used.  From a PCI compliance perspective, this sounds like a very secure approach and it is.  However, because of Speedpass, franchised operations have to send their Speedpass transactions through Exxon/Mobil’s central data center.  That data center is where the Speedpass RFID serial number is translated to a credit card number that the Speedpass customer entered into the Exxon/Mobil Web site.  That credit card number is then used with the franchisee’s merchant number to process the transaction.  As a result, Exxon/Mobil is on the hook for not only their own PCI compliance, but also all of their franchisees that accept Speedpass.  The lesson of Exxon/Mobil is that if the franchiser requires franchisees to process their transactions through the franchiser’s data center, then the franchiser is responsible for everyone’s PCI compliance.  The franchiser also is responsible for the monitoring and compliance of all franchisees.

Then you have the franchises that integrate sales and inventory management with corporate to ensure accurate ordering of material and to get daily sales figures.  No cardholder data is ever involved.  Most of these older solutions transfer their data at the end of day via FTP or some other batch data transfer method.  These sorts of solutions keep the franchisee and franchiser separated, so PCI compliance is straightforward.  In these instances, the franchisee just treats the franchiser as a service provider and files their own PCI compliance documentation.

However, in this age of total integration, newer solutions fully integrate the front of the business to the back of the business all to a central data center, regardless of the legal relationship between the parties.  The franchiser is typically not accessing individual sales transactions, they just want to know how many of each item has been sold and they want visibility into a store’s inventory data in real time.  This integration is also key to many franchise e-Commerce operations such as online ordering with in-store delivery, reservations and other customer friendly functions.  All of this integration means that the franchiser’s systems are then passing cardholder data (CHD) to the franchisee and possibly sending CHD the other way as well.

To add insult to injury, the franchiser, under the guise of making all of this technology easy to operate for the franchisee, provides help desk and IT operations management to the franchisee.  Where this all goes wrong is that now the franchiser’s IT personnel have access to the franchisee’s networks and computer systems and, possibly, CHD.  Regardless of whether or not CHD is involved, the franchiser has remote access to the franchisees’ systems, which means that the two parties must rely on each other for PCI compliance.

In the end, PCI compliance in a franchise environment all depends on the responsibilities of each party.  If they are truly separate, then there are no compliance conflicts between the parties.  However, when the franchiser begins providing PCI in-scope related services and/or technology solutions to their franchisees, then the franchisee relies on the franchiser for their PCI compliance and the franchiser is on the hook for that compliance.

Compensating Controls

A lot of organizations are relying on numerous compensating controls to achieve their compliance with the PCI DSS.  For version 1.2 of the PCI DSS, compensating controls have two new requirements and these new requirements will have the potential to cause a lot of organizations to become non-compliant.  As a result, I expect to find the next year very painful for our new clients as we explain these new rules and they attempt to come up with the documentation to keep their compensating controls.

There are now six requirements to the Compensating Controls worksheet.  The original four:

• The PCI DSS requirement that cannot be met;
• The control objective(s) of the PCI DSS requirement;
• The business reason(s) why the PCI DSS requirement cannot be met; and
• The compensating control(s) that have been put into place to achieve the PCI DSS requirement.

In addition to the original four requirements, two more have been added.  Those requirements are:

• Validation that the compensating controls are functioning as defined; and
• How the organization maintains the compensating controls.

The easier of the two new requirements is how an organization maintains the compensating controls.  However, while it is the easier of the two from a discussion standpoint, the fact that an organization must be able to document its maintenance processes for controls could be problematic.  In most organizations, the change control process for the control environment is typically not documented.  As a result, most organizations will have to adopt their change control processes for other business issues and just apply it to changes to their control environment.

The other new requirement is the one that most organizations will struggle with, providing documentation that the controls they are using to compensate for their lack of meeting the PCI DSS requirement are functioning as designed.  While this sounds simple and straight forward, I can tell you from personal experience that a lot of the compensating controls that were documented under v1.1 of the PCI DSS cannot provide this sort of proof.  In addition, a lot of compensating control cannot undergo the scrutiny of testing required to determine that they are functioning as designed.

So, where is the problem?  An organization must prove that it walks the walk, not just talks the talk.  This is where the wheels typically come off the bus.  It is very easy to say that something is a control; it is another thing to be able to actually prove it.  Organizations will have to provide documentation in the form of completed checklists or other formal documents that proves that the control is not only being used but that if a control exception occurs, the exception is addressed.  In addition, the QSA will also have to observe these processes at work so that they can satisfy themselves that the control is functioning.

I am not saying that compensating controls are a bad thing.  There are instances where organizations have no other choice.  The most common issue in this category is the database that takes more than 9 to 15 months to re-encrypt in order to change encryption keys.

In my experience, though, there are even more organizations that are using compensating controls because it is an easy out.  One of the most common reasons is that they need to avoid a large expenditure.  There are also those organizations where meeting the requirement will take a cultural change that management cannot step up to make.  There are also those organizations that just despise being told what to do and are just digging in their heels.  And, finally, there are those organizations that just plain do not want to have to get off their rear and do something.  For organizations like this, the jury rigging and hurdles they go through to make a compensating control work is mind boggling and, more often than not, costs more in time and resources than just meeting the original requirement.

If your organization is relying on compensating controls to be compliant with the PCI DSS, then you will want to make sure that you absolutely have no other alternative than a compensating control.  You should do an analysis of what it costs to maintain and comply with the compensating control versus implementing the PCI DSS requirement as written.  I would say that in about 85%+ of the cases, you will find that meeting the original requirement can be achieved easier and cheaper than using the compensating control.

PCI Check Box Compliance – Volume 1

We just started an engagement with a new client a week ago.  While reviewing documentation, we came across this situation that I had to share because it points out how some QSAs out there just want to check a box and not use their heads.  It is this sort of mentality that gives all QSAs a black eye and it needs to stop.

In order to meet requirement 5 of the PCI DSS, one of the biggest QSACs required our new client to get anti-virus software for their IBM iSeries (aka AS/400) mainframe.  The rationale?  If there is an anti-virus solution published for an OS platform, there must be a virus or malware out there that it protects it from.  Whoa!

This client also has AIX running, IBM’s UNIX derivative.  Technically, ClamAV can be recompiled and installed on AIX, yet the QSA did not tell the client that they needed anti-virus on AIX.  So much for consistency.

Even without a decent technical background, a review of the Web sites offering anti-virus solutions for the iSeries would tell you that your logic was patently wrong.  All of the anti-virus solutions for the iSeries are very clear that the iSeries does not have any viruses or malware, but it can be a carrier if you have mountable file systems for Windows or UNIX defined on your iSeries.  In the case of this client, they do not have any mountable shares, so there is no risk.

However, if you do have an iSeries that has implemented Windows or NFS shares, there is a much simpler way to handle this situation.  Just use one of your existing systems that does have anti-virus installed to scan the mountable shares on the iSeries weekly.  We had recommended this sort of approach for years for NetWare environments which had notorious problems with anti-virus solutions that were installed under NetWare.  The NetWare shares were scanned by a Windows system that had administrator rights so it could scan everything in the mountable volumes.

I will not bore you with all of the technical details, but there are a number of reasons why an iSeries, or IBM zSeries, Unisys ClearPath and other ‘old’ technology systems for that matter, cannot be infected like a PC.  These mainframe systems are almost impossible to infect directly if they are running their ‘old’, proprietary operating systems such as zOS, MCP and the like.  The controls surrounding true ‘root’ access on these OSes are such that you really must be a ‘Geek God’ to have such rights.  Even systems programmers in these environments do not have those kinds of rights.  And then, even if you did have the ultimate rights, there are other controls in place that would only allow your code to function on a particular computer complex, so it would not necessarily be transferrable to another system.  So much for infecting others.

But there is a risk with these platforms.  Most of these systems also will run slightly modified versions of Linux and UNIX and those can definitely be infected.  In those cases, all bets are off and you need to treat this big iron just like their Intel brethren.

So, the lesson to be learned from this experience?  If you do not have expertise with a platform, find someone that does have that expertise.  After all, not everyone working on a PCI assessment must be a QSA.  The QSA just needs to always be on-site when the work is being performed.  So, use someone in your organization that has the platform expertise or find a sub-contractor that has the expertise, but do not try to wing it.  Winging it only makes all of us look bad.

Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

• The PANs can only be displayed one at a time.
• You have to be in administration mode to view the PANs.
• The PANs cannot be printed out.
• The PANs are stored in memory, not on a hard drive.
• The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.”

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.