Visa’s Corporate Franchise Servicer Program

My friend, Walter Conway has a great article posted on StoreFrontBackTalk.com regarding this “wonderful” new program and category of third parties for franchise operations where the franchisees’ computer systems are tied to franchiser’s computer systems.  Visa thinks that regardless of whether cardholder data flows back to the franchiser’s systems, if these systems and networks are connected and there is no segmentation of the cardholder data environment, then the franchiser needs to register as an Corporate Franchise Servicer with Visa.  This change will likely create a real mess for a lot of franchise operators particularly hoteliers and certain fast food chains.

UPDATE: We had a number of inquiries regarding this program and had to pose questions to Visa for clarification.  The first question posed was in regards to Web sites that just pass through cardholder data for reservations and the like.  We have always included those sites as part of an organization’s PCI assessment since they transmit cardholder data.  Therefore, they were not like the systems in the fast food industry where no cardholder data was processed, stored or transmitted and therefore not assessed as part of any PCI assessment.  Visa acknowledged that these sorts of Web sites will require organizations to register in their Corporate Franchise Servicer program.  Visa also acknowledged that in order for an organization to register for the Corporate Franchise Servicer program, the organization must file a Report On Compliance (ROC) with their application.

Advertisement

The Threat Landscape Is Changing – Cloud Cracking

There was an article published on Threat Post this past week regarding a German security researcher that used a new feature of the Amazon.com EC2 cloud computing environment to crack SHA1 password hashes.   I am sure a lot of you are asking yourselves, “So what?  This is just another Chicken Little warning that come out all of the time.”  I would agree with you that publications use highly threatening headlines to hype these sorts of articles to attract readers.  But if you read these articles closely, ignoring the hype factor and think through the concepts that they are discussing, you can understand the threat they might bring to your environment.

The thing that caught my eye about this threat is that it cost the researcher less than an hour of their time and a whole $2.10 to crack six character length 160-bit SHA1 hashes.  Even more disconcerting was that all of the necessary hardware and software was readily available through the EC2 service.  And if the researcher had desired, they could have used even more GPUs to shorten the time to crack these hashes.  Granted, the researcher only cracked 14 of these hashes, but what if those hashes were to one or more administrator accounts?

I am sure a lot of you are now saying, “Yeah, but, this is all theory and not a ‘real’ threat.”  No doubt about it.  I too have been known to toss out my famous, “In theory, theory works,” at this point.  But the only way to determine if the research really is a real threat is to read the article or research paper and then determine if the threat can truly be applied in the real world.  Based on what I have read about this threat, I would say that there is a great potential for misuse of this EC2 service for all sorts of encryption attacks, not just SHA1 hashes.

A lot of you are now probably pointing to the fact that these were all six character long items that were hashed.  I would agree but then also point out that they were 160-bit hashes, not less than 128-bit.  A lot of security professionals mistakenly believe that if they get hashes or encryption above 128-bit, that everything is secure.  However, the number of bits is not the only factor; there is also the strength of the key used.  If the key is not very long or is easy to guess, then it does not matter how many bits are used by the algorithm.

A lot of security professionals blow off threats because they just assume that if they are scanning regularly that any new threat will be caught by their scanning.  Unfortunately, scanning only looks for vulnerabilities to devices based on known attack vectors, not a threat like this one.  This threat comes into play with any encrypted data or transmissions that an attacker can come across and may or may not have a lot to do with vulnerabilities.

You can argue that because you scan and you comply with the PCI DSS and do not have any vulnerabilities of CVE 4 or higher, you are therefore secure.  However, as any network security professional that conducts penetration testing will attest, vulnerabilities with a CVE of less than 4 can be put together and used to compromise a network.  So, just because you do not have any vulnerabilities of CVE 4 or higher, does not necessarily mean that you are secure.

The real threat here is that should an attacker be able to get a hold of your encrypted data or data flows, they can just load it up and use Amazon.com’s EC2 cloud to attempt to break the encryption.  As a result, all of those claims over the years by security pundits that attackers would have to have access to supercomputers have apparently been realized with the advent of cloud computing.

But again, this is all theory, right?  You wish.  Even more shocking was a tidbit tucked away in the article.  There is a site entitled WPACracker.com that offers a 400 CPU cluster of computers and 284 million word dictionary and promises to crack WPA passwords on an average of 20 minutes for $17.  As a result, all of you relying on WPA to secure your wireless should be considering upgrading to WPA2 as soon as you can.

The next thing that rolled through my mind is what if some enterprising individual decided to conduct some “research” for themselves by using the Berkley Open Infrastructure for Network Computing (BOINC) platform?  This is the platform that runs SETI@home, Einstein@home and other worthwhile scientific research projects that need lots of computing power.  Based on the BOINC home page, that would put the potential of over 4,000 teraflops at the command of our “researcher.”  However, like all things technology based, our enterprising researcher would need to find a potential vulnerability in BOINC and leverage that to gain access to all of that computing power.  Either that or make their research project look enticing to the BOINC user population so that they add that workload to their systems.  But given that BOINC is open source, it is also possible that attackers could create their own BOINC network for the purposes of cracking encryption.  I could imagine botnets being put to this purpose.

This whole threat plays out best when the attacker has inside access to an organization’s network and data.  Reading the latest reports from Verizon Business Services and Trustwave, the majority of breaches have an inside component, so it is not too farfetched that an insider would have access.  So, if you are not monitoring your network and sensitive data and not strictly controlling access to your data, then it is anyone’s guess as to whether or not someone has taken your data and is now attempting to decrypt it.

If you learned anything at all from this post is the fact that attackers are leveraging cloud computing just like the rest of us.  The unfortunate aspect is that attackers are leveraging the cloud to continue their questionable and sometimes illegal activities.  And in so leverage this new technology, the potential that they are successful is only going to go up.

Can You Trust Your QSA?

A great question that gets asked often these days.

It is also the title of a great article in the November 2010 issue of Digital Transactions that documents the dilemma faced by QSAs and merchants regarding PCI compliance.  Give it a read and take a walk in a QSA’s shoes.

There Are No ‘Silver Bullets’

For the last time, there are no single ‘silver bullet’ solutions to perfectly securing cardholder data and their related transaction flows.  As my blog shows, I get comments from all sorts of people saying otherwise.  However, whether you are talking about Chip and PIN, end-to-end encryption, data encryption or tokenization, none of these technologies offer the complete solution to stopping credit card fraud.

Chip and PIN

Chip and PIN was developed to address the problem of face-to-face transaction fraud.  It does not solve the problem of cardholder data being breached in back office systems where most breaches take place.  The attackers know that somewhere in the transaction flow process, someone has to have the cardholder data.  Chip and PIN does not address the back office and never will.  It is not that Chip and PIN is a bad idea, it is the fact that implementing Chip and PIN does not, in and of itself, solve the issues faced with breaches.

End-To-End Encryption

End-to-end encryption requires that each end uses the same encryption process.  So the first problem is that each acquiring bank or service provider will likely have their own particular implementation of end-to-end encryption meaning that interoperability will not exist.  So those merchants with multiple processors will likely have problems with end-to-end encryption unless they use separate systems.  However, that is minor compared to the next issue.  The other problem is that there are a lot of ISOs and service providers in the transaction flow that require access to the transaction making end-to-end encryption not quite as easy as one might think.  However, the biggest problem with end-to-end encryption is that it only protects the cardholder data from one endpoint to the other endpoint.  It does nothing about protecting the endpoints themselves or the environment outside of the endpoints.  As a result, the endpoints and the environments outside the endpoints become the targets.  While the endpoint at the processor or acquiring bank is likely fairly well protected, the endpoint at the merchant is probably the weak link and therefore the merchant is still the target.  The most likely target here is doctoring the card terminals or POS software so that the attacker can gain access to the cardholder data before it hits the encryption process.  End-to-end encryption does nothing to prevent the tampering of the endpoints.  As with Chip and PIN, end-to-end encryption only addresses a part of the problem.

Data Encryption

Data encryption is great for protecting the data when it is stored as well as when it is in transit.  However, unlike end-to-end encryption, under data encryption when data is in transit there are multiple points where the data is decrypted and encrypted as it moves through the authorization and payment processes.  Any one of these points could be compromised and the data encryption defeated.  Cardholder data that is stored encrypted still has the threat of being compromised either at the point it is encrypted or if the encryption key be compromised.  If data is only encrypted during transmission or if it is only encrypted when stored, the data is susceptible to compromise wherever it is not protected.  As with end-to-end encryption, data encryption can solve a portion of the problem, but not the entire problem.

Tokenization

Tokenization is the act of creating a value, the ‘token’, and using the token as a way to reference the actual cardholder data.  Tokenization is great for merchants because it allows them to keep their old systems running unmodified by having the system believe it is getting back the PAN when in fact it is just a token.  However, the cardholder data still has to be transmitted in order for a token to be generated, so the merchant is still not out of scope.  Worse yet, if the transmission is not protected, then the data stream is susceptible to compromise.  As with all of our other solutions, tokenization is also not a complete solution.

The bottom line is that none of these technologies individually is the answer to our security issues with cardholder data.  However, if they are used together, they can provide a formidable defense against compromise.  But why is that?  As with all good security solutions, it involves defense in depth.  Since there is no single, ‘silver bullet’ that can solve the problem, we have to look at multiple solutions that, when put together, create a defense in depth approach to provide as much security as possible.

By using Chip and PIN in conjunction with end-to-end encryption, data encryption and tokenization, we create a gauntlet of protection.  However, as I always like to remind people, security is not perfect and even this solution is not a ‘silver bullet’.  There are controls and monitoring required ensuring that endpoints remain secure, encryption keys are protected and that endpoints are not tampered with.  However, such an approach would go a long way to minimizing the threat of compromises.

Issuers and Financial Institutions

The applicability of the PCI DSS to issuers and financial institutions in general has been a topic of discussion with QSAs as well as the entities involved.  Over the years, I have fielded a lot of questions regarding the applicability of the PCI DSS to such organizations.

A lot of issuers feel that they are not within the purview of the PCI DSS and point to the fact that the PCI DSS is for merchants and service providers.  Financial institutions for the most part outsource their credit card processing so they also feel that they do not fall under the requirements of the PCI DSS.  However, with the release of PCI DSS v2.0, the PCI SSC has burst these organizations’ bubbles and let them know that the PCI DSS is for any organization that processes stores or transmits cardholder data.

Just so we are clear on terminology, an issuer is defined by the PCI SSC as an, “Entity that issues payment cards or performs, facilitates, or supports issuing services including but not limited to issuing banks and issuing processors.  Also referred to as ‘issuing bank’ or ‘issuing financial institution’.”  The PCI SSC does not define a financial institution, however for the sake of this post, a financial institution is defined as; state or federally chartered banks, thrifts (aka savings & loans) or credit unions, insurance companies, brokers, securities dealers or investment funds.  These are terms familiar to US QSAs, but they would also apply to any similar financial institutions around the world.

Issuers are the ‘Fort Knox’ for carders.  This is because an issuer stores all of the cardholder data that is contained on the magnetic stripe and chips of all credit and debit cards created for their customer financial institutions.  For a variety of business and legal reasons, issuers need to retain this cardholder data.  Obviously, if an issuer were ever to be breached, it would cause serious problems for all of the financial institutions that the issuer serviced.

Issuers always pointed to requirement 3.2 in the PCI DSS that does not allow the storage of sensitive cardholder data as to why the PCI DSS did not apply to them.  With the release of v2.0, the PCI DSS, the PCI SSC has modified the standard to clarify how the PCI DSS requirements apply to issuers.  These clarifications had been in place for years and discussed at some QSA training sessions, but were not always widely understood by the QSA community, let alone a lot of the issuing banks.  As a result of the clarifications in v2.0, QSAs will be able to apply the PCI DSS to issuers without any of the previous questions regarding applicability.

Financial institutions are a more problematic group.  Since most, if not all, of these types of organizations are regulated under state and/or federal laws, they feel that they have enough to deal with let alone the PCI DSS.  Until recently, the card brands have agreed with the financial institutions’ assessment and have left them alone.  The rationale has been that a lot of those regulations require these financial institutions to meet a majority of the PCI DSS requirements.  However, in the view of the PCI SSC and the card brands, these regulatory requirements are not the complete PCI DSS requirements.  Over the last two years, we have started to receive more and more requests from somewhat shocked financial institutions that are being asked by their service providers to provide them with a Report On Compliance (ROC) regarding the ATM networks that these financial institutions operate.

Where all financial institutions are beginning to feel the PCI compliance heat is over their debit cards or check cards.  Debit cards are similar to credit cards in that they are branded by one of the card brands.  However, unlike credit cards, debit cards are tied directly to a checking or savings account at a financial institution.  If you do not have enough money in the linked account, then a purchase with a debit card will not be approved.  Debit cards also can function as a customer’s ATM card and requires a four digit PIN to obtain cash at an ATM.  Some merchants will also process debit card transactions using a PIN and not require a customer’s signature on a receipt similar to a Chip and PIN card in Europe.

Unlike credit cards where the financial institutions have totally outsourced their processes, debit cards create a PCI compliance issue because they require that a financial institution have the primary account number (PAN) of the debit card stored on their system in order to link the debit card to the customer’s checking or savings account.  As a result, financial institutions providing debit cards to their customers have cardholder data stored on their computer systems.  And that act does come under the purview of the PCI DSS.

Financial institutions argue like issuers that the PCI DSS is a merchant and service provider program.  You will also hear them argue that the fact that they are state or federally regulated also puts them outside complying with the PCI DSS.  All of this is a smoke screen.  If any of these financial institutions went back and reviewed their contracts with the card brand, they would see that they too are required to comply with all of the relevant PCI standards.

The bottom line is that even issuers and financial institutions are in-scope for complying with the PCI standards.  If they think otherwise, they should have their legal counsel review their card brand contract and amendments.  They will find out otherwise.

Requirements That Are Never ‘Not Applicable’

Believe it or not, there are two PCI DSS requirements that can never be marked ‘Not Applicable’.  According to the PCI SSC, requirements 1.2.3 and 11.1 can never be noted as ‘Not Applicable’.

Requirement 1.2.3 states:

“Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.“

Even if an organization does not have wireless, the PCI SSC has stated that this requirement may never be marked as ‘Not Applicable’.  The QSA is required to document the network and describe any wireless the organization has implemented, regardless of whether or not the wireless has any contact with the cardholder data environment.

While this may seem a little over the top, think about why it is included in the PCI DSS.  One of the largest breaches that ever occurred was the result of a poorly engineered and operated wireless network.  As a result, to prevent future breaches due to wireless networking, the PCI DSS requires that the QSA ensure that any wireless, in or out of scope, is evaluated to determine if it is securely implemented.

When an organization does have wireless networking implemented, the PCI DSS requires that wireless networking to be segregated from the cardholder data environment (CDE) whether the wireless is used to carry cardholder data (CHD) or not.  Again, this is in response to the large breach.  Wireless is broadcast over public airwaves and an organization cannot be assured that someone is not eavesdropping on that broadcast.  However, it is this broadcasting over public airwaves that trip up most organizations.  People neglect or forget this fact and do not put in place the appropriate security and controls over wireless networks.  As a result, the PCI DSS is trying to ensure that should wireless be compromised, the entire network is not also compromised by default.  That then requires that controls such as ACLs and/or firewall rules are put in place to restrict traffic flow between any wireless networks and any other networks.

And even if an organization does not have wireless networking, under this requirement the QSA is required to document what procedures they used to determine that there was no wireless implemented.

As a result, a QSA is not allowed to place a ‘Not Applicable’ for this requirement.

As with requirement 1.2.3, requirement 11.1 was also put in place in response to that large breach as well as a number of other, unrelated breaches.  This requirement is also in response to the low cost of wireless networking equipment and the ease with which it can be implemented in a stealthy manner thus providing an attacker with a way into an organization’s network.  For reference, requirement 11.1 states:

“Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”

Whether an organization has wireless networking or not, the PCI DSS requires that the organization periodically assess its wireless networking posture to ensure that either wireless is still not present or that if wireless is used, that only the organization’s wireless is present on their network.

For an organization with only one or a few locations, this requirement is not that onerous.  However, for a Wal*Mart or Target with thousands of locations, scanning each of those locations on a quarterly basis is daunting.  As a result, you get wireless intrusion solutions such as those from Motorola and AirTight to automatically detect unapproved wireless devices.  While these solutions meet the requirements of 11.1, they can be expensive and difficult to implement, monitor and manage.  There is the alternative of implementing other controls on the network which can also be used to meet this requirement that I have discussed in another blog entry.  However, this compensating control has its drawbacks as well.

As with requirement 1.2.3, no organization can mark requirement 11.1 as ‘Not Applicable’ just because they do not have wireless networking implemented.

At the end of the day, the bottom line here is that all organizations are required to ensure that wireless networking is either not present on their network or, if present, it is only their wireless devices and that those wireless devices are appropriately implemented and secured.