01
Jul
14

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.

About these ads

7 Responses to “The Flaw In Requirement 8.5.1”


  1. 1 QSAstep
    July 8, 2014 at 10:26 AM

    Thought provoking as always. I think 8.5.1 is also relevant here. It requires that vendor access is only enabled when needed and is monitored in use. Granted that won’t help if the entire POS process has been outsourced to a service provider. But if we are talking about support for systems managed by the merchant then I think it would apply and it ought to stop this sort of attack.

    • July 8, 2014 at 6:29 PM

      Agreed. But that is the problem in today’s outsourced world. The outsourser is in control, not the merchant because the merchant knows nothing about the POS and does not want or need to know. That is the outsourcer’s responsibility.

  2. July 7, 2014 at 12:39 PM

    This has really made me think about a service provider I use (in a non-PCI context). I’ll be pointing them here and asking what their approach is…

  3. July 3, 2014 at 11:30 AM

    The problem is that the “expert” isn’t one in security, which is what PCI addresses. It seems like the number of breaches that result from service providers providing security services that they are not qualified to do. Also the merchant has the responsibility to enforce 2 factor authentication for remote access to the CDE (PCI DSS req 8.3). POS support I would consider in this category. I totally agree with your response to the comment above about franchisee operators wanting to outsource everything possible but ultimately PCI compliance falls to the merchant. They need to make sure they are meeting all the applicable PCI DSS requirements and also ensure their service providers are qualified for the services they are providing.

  4. 5 jbl
    July 2, 2014 at 2:13 AM

    Another complementary approach to address this issue might be to monitor remote connections by vendors. If connections come up outside of service hours, or without any ticket requiring such connections, the merchant might detect the attack early on and be able to disable the compromised account for instance. Of course, it depends on the nature of the service being provided.
    Just a thought…

    • July 2, 2014 at 6:05 AM

      Good idea and recommendation. But remember, in a typical franchisee environment, that is probably more than the franchisee wants to take on. The reason is that most franchisees are not large operations. They may have only a single store or they may have up to five. They outsource for the vendor’s expertise with POS, changing fry oil, etc. as well as to get one more problem off their plate. They trust that the “expert” knows what they are doing.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

July 2014
M T W T F S S
« Jun   Aug »
 123456
78910111213
14151617181920
21222324252627
28293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 949 other followers


Follow

Get every new post delivered to your Inbox.

Join 949 other followers

%d bloggers like this: