The Flaw In Requirement 8.5.1

Today it was unceremoniously announced that a number of major restaurant chains’ franchisees had been potentially hacked between February 28, 2014 and April 18, 2014 because their point of sale (POS) vendor’s remote access account had been compromised.  I say franchisees because I know a couple of these restaurant chains’ corporate operations and they were not using a third party to manage POS.

In a nutshell, the attackers gained access to the POS vendor’s LogMeIn account.  LogMeIn, like a lot of similar remote access facilities, has an address book where you can store remote access credentials.  So with access to LogMeIn, by default, the attackers had access to the address book that contained credentials for any customer environments in the address book (likely all customers, but possibly not).

To remind everyone, requirement 8.5.1 of the PCI DSS v3 states:

 “Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.”

The PCI SSC guidance for requirement 8.5.1 states:

 “To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer. Technologies, such as two-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.”

It is likely that the vendor was trying to get a jump on complying with requirement 8.5.1 in the PCI DSS v3.  However, this vendor may have been using such an approach all along to manage customer remote access which is also not uncommon with technology companies.

The first thing to note is that requirement 8.5.1 is a best practice until June 30, 2015 after which it becomes a full requirement.  However, as I pointed out in an earlier post, a lot of vendors will likely have to start rolling out a remote access solution as soon as possible to minimize service level agreement (SLA) issues.

One of the most likely ways vendors are addressing compliance with 8.5.1 is through services such as LogMeIn, GoToMyPC and similar services.  These are inexpensive services available to any organization or anyone.  There are also enterprise solutions such as those from Bomgar and the like that purport to have better security.  However, all of these solutions share the concept of an address book to make gaining remote access easier for the vendors’ users that rely upon them.  And that is their Achilles’s heel.  If an attacker gains access to the remote access service, they gain access to the address book and, therefore, to the customers’ credentials stored in that address book.  Game over.

It is important to note though that what this vendor was doing fully complies with requirement 8.5.1.  But even though this service provider was complying with the intent of 8.5.1, the implementation was flawed.  This is just another example of how PCI compliance does not mean that security issues cannot still occur.

How easy is this to happen?  Think a spear phishing attack against any vendor that does remote support and maintenance.  Regardless of the customer credential management solution (in-house or cloud based), once access to the credential management solution is compromised any concept of customer security is over.

So what should vendors being doing to mitigate this situation?  Exactly what our vendor who was breached did, implement two-factor authentication on the credential management system.  Spear phishing attacks will not be successful because even with the credentials to LogMeIn or similar, the attacker will need the second factor.  Yes, the attacker can still compromise the support person’s desktop, but they will not have access to customer credentials.

Trouble is, some vendors will want a cheap two-factor solution meaning something that sends out codes via SMS, email or telephone, versus RSA SecurID or SafeNet to name a few.  Solutions over SMS, telephone and email have a variety of known vulnerabilities and can easily be intercepted or even redirected.  In the case of LogMeIn, they indicate that they only support SecurID.

Regardless, all of you service providers out there that have remote access to your customers managed by some enterprise credential management solution, please implement a strong two-factor authentication solution on your customer credential management solution before you too become a newspaper headline.

I would like to believe that this vendor thought they were doing the right thing and got burned because of how they implemented their solution.  At least they stepped up and fixed it the right way.  Unfortunately, this is how we sometimes learn, from our mistakes.

Advertisement

Why SAQ A-EP Makes Sense

A colleague of mine attended the PCI SSC QSA Update session at the ETA convention a couple of weeks back.  One of the big discussion items was how the Council is being pilloried over SAQ A-EP.  This SAQ was developed to address the recommendations that were documented in the information supplement titled ‘PCI DSS E-commerce Guidelines’ that was published in January 2013.  Specifically, SAQ A-EP addresses the ecommerce sites that do redirects to a processor’s site that does the actual payment processing.

Based on the comments I have seen online and made in personal conversations, you would think that SAQ A-EP was heresy or a bad joke.  All of these derogatory comments are being driven by merchants that were sold a bill of goods by slick, non-PCI informed, sales people pushing redirected ecommerce solutions by claiming that it put the merchant entirely out of scope.  This was not the case and never was the case, particularly after the issuance of the information supplement.  However, we still encounter outsourcing vendors that continue to claim a redirect approach puts the merchant entirely out of scope.

To understand the rationale of SAQ A-EP we need to understand the risk surrounding these redirect solutions.  The risk is that an attacker modifies the redirect on the merchant’s server to now point to their own payment page, collects the customer’s cardholder data (CHD) on the attacker’s page and then, optionally, passes the customer on to the original payment page at the processor so the customer and merchant are none the wiser.

Under the PCI DSS and card brands’ security programs, redirect systems are still in-scope for PCI compliance because they are a key control in the payment process even though the merchant’s server issuing the redirect does not come into direct contact with CHD.

With all of that said, SAQ A-EP is not a full SAQ D, but it is not as short and simple as SAQ A either.  There are a lot of requirements to be met with SAQ A-EP which is why merchants are up in arms.  However, if you understand the aforementioned risk, you should understand why the requirements that have to be complied with in SAQ A-EP are there.

The requirement 1 requirements are all there to ensure that there is a firewall protecting the server that does the redirect.  This is Security 101 and I would doubt that any merchant would not have a firewall protecting all of their Internet facing servers.  Routers have always been optional and if the merchant does not have control of those devices, then they would not be included here.

Requirement 2 is all about making sure that all devices in the cardholder data environment (CDE) are properly configured and security hardened.  Again, this is Security 101 stuff.  If a merchant is not doing this for Internet facing devices, they are just begging to be attacked and compromised.

The requirements called out in SAQ A-EP for requirement 3 are there to confirm that the merchant is not storing cardholder data (CHD) or sensitive authentication data (SAD).  A merchant using a redirect should be marking these as Not Applicable (NA) and documenting that they do not store CHD in their system(s) because they use a redirect that processes and transmits CHD directly between their processor and their customer.  Any merchant that answers these requirements any other way should not be using SAQ A-EP.  All of that said, merchants need to have proof that they examined logs, trace files, history files, databases, etc. and did not find any CHD or SAD in those files.

Requirement 4 is provided to ensure that secure communications are used.  I would recommend documenting the SSL/TLS certificate information for your processor for the requirements in 4.1.  But do not pass over requirement 4.2.  A lot of ecommerce only merchants have call centers or take telephone calls and do order entry into the same Web site used by their customers.  As a result, merchants need to make sure that email, instant messaging, etc. are never used for communicating CHD/SAD.

Requirement 10 is important for any forensic research should the redirect be manipulated so that it can be determined when that event occurred so that the scope of any compromise can be determined.

While one would think that the vulnerability scanning and penetration testing requirements in requirement 11 would be thought of Security 101 and self-explanatory, you would be surprised at how many merchants argue about that fact.  Again, the driver of these redirect solutions was cost reduction and vulnerability scanning and penetration testing incur costs, sometimes significant costs depending on the number of servers, firewalls, load balancers, switches, etc. involved.  If you do not do vulnerability scanning and penetration testing as required, how do you know that the redirect system(s) are properly secured and patched?

However, the key requirement that cannot be missed is requirement 11.5 regarding critical file monitoring.  That is because the whole security of the redirect environment is pinned on detecting any modification of the redirect URL.  All of the other requirements in SAQ A-EP are there to minimize the risk of compromising the redirect.  11.5 is there to ensure that, if the other controls fail, at least the merchant would be alerted to the fact that the redirect had been changed.  If a modification to the redirect cannot be reliably detected by the critical file monitoring solution, then the security of the redirect cannot be assured.

The remaining requirements for 5, 6, 7, 8, 9 and 12 are all Security 101 items.  If you are not following these requirements as part of best practices for security and IT operations in general, then you need to consider what exactly you are doing.

Hopefully everyone now understands SAQ A-EP and why it is not as simple as that slick sales person implied.

PCI DSS v3 Requirement 10.6

I was on a call the other day and we were walking through requirement 10 of the PCI DSS v3 to ensure we had everything covered regarding changes.  One of the other people on the call gasped and told all of us to look at requirement 10.6.

 “Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.”

The person who gasped said, “You don’t think they mean ALL other systems as in everything do you?”

We all looked at the Guidance column for advice and saw that it said:

 “Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems.  The frequency of the reviews should be determined by an entity’s annual risk-assessment.”

The tests 10.6.1 and 10.6.2 also refer to “all other systems” as well.  In the end, we came to agreement that the new version of the PCI DSS does call out that all systems, even those out of scope, need to have their log data reviewed based on their risk to the organization.

Talk about a “How in the Hell did we miss that?” kind of moment.

Worse is that we know a lot of organizations are going to push back very, very hard on this requirement.  They sized their security information and event monitoring (SIEM) solution based on their cardholder data environment (CDE) and Category 2 systems, not their entire networks.  But it gets even worse because this is not a requirement that you can put off until 2015, this requirement needs to be complied with immediately when going to the new version of the PCI DSS.  Oops!

But if this is not enough, the Council used that word “periodically” in the requirement.  In the guidance they state, “The frequency of the reviews should be determined by an entity’s annual risk-assessment.”  So there is another requirement for the risk assessment.  Your risk assessment must define why log data of all systems is only reviewed once a month/quarter/year/etc.  However, if you are routing all log data from all systems/devices into a SIEM, it should be reviewed in almost real-time.

Congratulations to all those SIEM vendor sales people out there as it will likely be a very good year for all of you.

Just wanted to provide you all with the heads up.

Why The Paradigm Must Change

The Target, Neiman Marcus and the potential other breaches of retailers to come should be a learning moment for all of us to demand that the card brands change their business paradigm to one that is more secure.

Bolt-Ons Do Not Cut It

For all intents and purposes, how a credit card works has not changed since the late 1950s when they were introduced.  Yes, there have been advancements such as EMV, 3D Secure and end-to end encryption (E2EE), but those are all things that just bolt onto the original concept.  The trouble is that, given today’s technologies and their capabilities, the card and the bolt-ons are just no longer providing the security they once did.

With the Target breach there has been a call to get the US to finally convert to EMV.  The trouble is that EMV would have leaked enough information for fraud to be committed as well, so it is not an answer.

Trade association spokespeople trotted out 3D Secure and other methods of securing online transactions.  The trouble is that most merchants eschew 3D Secure and its kind.  In addition, there are known vulnerabilities with these supposedly secure payment methods so they also have potential issues that could be exploited.

Then there is E2EE also known as point-to-point encryption (P2PE) from a PCI perspective.  These also can be exploited.  It may be more difficult, but when you are determined to gain access to sensitive information, that does not matter.

After the release of the PCI DSS in 2008, a lot of retailers implemented a variety of E2EE solutions.  Unfortunately, the endpoint at the retail location was the POS register and not the terminal.  This was not due to merchants’ negligence; this was due to how their POS applications operated.  This allowed for attacks such as that used in the Target breach to succeed.  All the attacker has to do is insert their malware into the POS process so that the malware can “see” the cardholder data before it gets encrypted.

Even in solutions that do E2EE/P2PE to the terminal can be defeated by taking the same approach and inserting the malware into the terminal process before the terminal can encrypt the data.  Worse yet, if the terminal is breached, the attacker can capture PINs if they also have malware that captures the keystrokes on the terminal before the PIN is encrypted.  There are a number of methods to minimize these risks at the terminal, but if the terminal supply chain is compromised as it was over a year ago in the Barnes & Noble breach, there is little a merchant can do to stop such attacks.

The bottom line is that all of these solutions are bolt-ons to the existing card paradigm and all still have risks that a breach could occur.

Using Complexity Against Us

Brian Krebs and others have wondered aloud how a sophisticated organization such as Target that has information security and forensic resources second possibly only to the government could have been compromised.  Particularly after the 2007 compromise by Albert Gonzales when Target totally revamped and increased their security posture to minimize the likelihood of another event.

The first clue to me came when I read the iSIGHT PARTNERS report on the Target breach.  The theme that comes through loud and clear is that the attackers are using the complexity of Target’s technology infrastructure against Target.  I mean how could FTP activity and huge data transfers (internal and external) go so unnoticed?

Actually, that was likely fairly easy.  The attackers used existing network traffic to mask their own network traffic.  They sought out servers that already had large volumes of traffic and put their data collection server on one of those servers that already had a lot of traffic.  Better yet, a server that was already running as an FTP server.  As a result, even with diligent monitoring, the increase in traffic likely did not raise any alarms.

People assume that such breaches are like a “snatch and grab” in the real world.  The attackers break into an organization’s network, quickly take what they can off of the computers they encounter and leave.  That was the modus operandi (MO) in the past, but not today.  Sophisticated and organized attackers such as those that breached Target, do what they can to remain unseen while they learn more about their victim.  They take their time mapping out the network and determining what devices they want to compromise to further their efforts to gain access to the sensitive information they seek.  Because of this, it is highly likely that the Target attackers encountered the Target customer database during their investigation of the Target network and took it first so that they would have at least something for all of their efforts.

The most insidious thing I think the attackers did was that they likely used Target’s software distribution system to disseminate their malware.  Given the number of POS systems compromised (around 51,000); I find it hard to believe that the attackers manually installed their malware on those POS systems.  It would have placed their operation at extreme risk likely resulting in its discovery.  By using Target’s software distribution system, the attackers got an added benefit of legitimacy to their malware because they Target themselves did the installation.  As such, the malware would appear as valid because Target’s software management system initiated the change.

Now What?

All of this brings up an interesting conundrum.  If attackers are stepping up their game and using such techniques, how do we detect them?  It is a very good question with no good answers.  The iSIGHT report offers methods to stop and eradicate this particular attack.  However, the next attack and the attack after that will all likely use different malware and different techniques to get the data out of your network.

We are in is a war of escalation with no end in sight.  Merchants step up their efforts to stop such attacks and the attackers adapt and adopt new techniques to breach organizations and gain access to their sensitive information.  What we need is a solution that stops the escalation and gets us out of this vicious circle.

That is why I am pushing the 15 – 16 character single use transaction code as that solution.  My reasons are as follows.

•  The algorithms already exist as a number of the card brands experimented with them a decade or more ago.
• It will work with existing POS technology and applications.
• It will work with existing eCommerce sites.
• It can be implemented into eWallet applications.
• It can be processed, stored and transmitted without encryption.
• It can be generated by PCs, smartphones, tablets, credit card sized devices and any other devices that have computational capabilities.
• It can be displayed on devices in a character format for manual entry or as one or 2D bar codes for scanning.
• It can be transmitted via swipe, EMV, near field communication (NFC), Wi-Fi or even Bluetooth.
• And best of all, it is secure by the very nature that it can only be used once.

There will be some changes that would be required at the transaction processors and acquiring banks to handle such a solution.  But given that some of the card brands already have experience with this solution, there is a body of knowledge that already exists as to how it needs to be implemented.

Let the discussion begin on how we move ahead with a better, more secure solution.

The Economics Of EMV

There are a lot of people out there that have apparently taken big swigs of the EMV Kool Aid and think that merchants and banks in the United States are all idiots for not believing in EMV.  Well folks, here is EMV by the numbers.  Unfortunately, the best set of complete numbers I could get are from 2009, but I know that the fraud percentages have not radically changed since 2009.

As this example will illustrate, EMV in the US is a non-starter, not because we do not like EMV, but because it makes no financial sense. While I am using Target as the example, these numbers are pretty much what most retailers (large or small) are looking at as they evaluate going to EMV.

• Target had around $65B USD in revenue for 2009 as reported in their Annual Report.
• For 2009, card fraud amounted to 0.11% according to a report from the US Federal Reserve Bank of Kansas City report on EMV adoption. For comparison, card fraud in the UK (the best in Europe and the best for EMV countries) is 0.08%, a 0.03% improvement over the US.
• We know that not all of Target’s revenue is in card transactions but I will estimate that 70% of revenue was card transactions (around $45.5B USD). Then Target has around $50M in losses related to card fraud for the year at 0.11%.  Therefore, assuming a 0.03% improvement in fraud due to implementing EMV, Target is saving around $13.5M USD a year.
• Estimating between $50M to $100M USD to replace the POS (possibly), terminals and software to support true EMV (for comparison, Target is already spending an estimated $25M to $30M just on new terminals), Target gets a payback on that $13.5M USD savings due to EMV in around four to seven years.

I can tell you from experience that, if a merchant cannot get a three year or less payback, they will not even consider the investment. A two year or less payback is actually preferred and the only sure way for any project to get management’s consideration and approval.

But while the financials for EMV do not add up, there are also other factors that are causing retailers to question a conversion to EMV.

One of the largest is the fact that EMV does nothing to stem the fraud losses from card not present (CNP) transactions. Since most retailers are viewing eCommerce as their next new retail opportunity, the exponentially increasing losses due to CNP fraud does not improve the likelihood of converting to EMV. And with that larger focus on eCommerce and maintaining brick and mortar margins, there is also the concern regarding investing significantly in any changes to those brick and mortar operations that also hold back retailers from transitioning to EMV.

Another consideration is that a lot of retailers just upgraded their terminals a few years back to comply with the PCI PTS requirement. Most retailers like to get at least seven to ten years out of their technology investments. Had Visa and MasterCard played their cards right and coordinated their EMV push with the PTS changes, the US likely would have converted to EMV.

Finally, there are concerns about EMV even surviving given the advent of new payment technologies such as eWallets as well as Bitcoin and other new forms of payments. As a result, a lot of retailers are sitting on the sidelines while technology and payment methods sort themselves out before considering making any investments in new payment process capabilities.

That my friends are the cold, hard facts of why EMV is currently dead on arrival in the US.

What You Should Take Away From The PCI DSS 3.0 – Part 2

It was published sooner than I thought.  But here is the remainder of the post on PCI DSS 3.0.

What You Should Take Away From The PCI DSS 3.0 – Part 2

What You Should Take Away From The PCI DSS 3.0 – Part 1

See my latest blog entry at the FishNet Security 6Labs blog.

What You Should Take Away From The PCI DSS 3.0 – Part 1

Part 2 will be published shortly and I will post the link here.

PCI DSS v3 and PA-DSS v3 – Wait For It

There are all sorts of QSAs and other experts who are weighing in on the new versions of the PCI DSS and PA-DSS that were released around the first part of November.  In my very humble opinion, all of this discussion is speculation, at best, because the PCI SSC has not released the final pieces of the standards puzzles.  Those final pieces are the respective Reporting Templates for those standards.  Without those templates, QSAs and PA-QSAs have no idea of what the true testing and reporting requirements they will be held.  As a result, the impact of the changes to the standards will not truly be known until QSAs and PA-QSAs have the templates and can review the new testing and evidence requirements.  While I am not expecting the sort of major changes that resulted when the version 2 Report Instructions were released, there still could be some surprises that could impact the amount of work and evidence collected.  The PCI SSC has not committed officially to a release date for the Reporting Templates, but the rumor is that they will be available around the first part of March 2014.

There are some comments that can be made and I will be covering some of those points on a Webinar sponsored by Tripwire on Monday, December 16, at 7PM UTC / 1PM CST.  If you care to attend, you can register for the session here.  “See” you there.

Hot Off The Press

The PCI SSC released the final versions of the PCI DSS v3 and PA-DSS v3 this morning.  You can get your copies here as long as you sign their agreement.  The Change Summary documents for both are also finalized and available in the library.  Enjoy!

P2PE Revisited

David Froud is on a roll.  Tenable’s Jeffrey Man wrote a post regarding point-to-point encryption (P2PE) and it apparently got the juices flowing.

I have discussed P2PE (known to almost everyone else as end-to-end encryption or E2EE) a number of times (see my Post Series References page).  Also see my post on What Happens Once Merchants Get Rid Of Cardholder Data to understand how the risks will shift and that the terminal becomes a large attack point.  This is why we need to get to some sort of single use code for a payment which is easily handled with today’s smartphones.

Read the posts and decide.  I think you will find that they both make compelling cases for why P2PE certification is a non-starter and is really not needed.