Posts

Basefarm at 2013 European PCI Community Meeting – PCI DSS 3.0

The annual European PCI Community Meeting was held in Nice, France from October 29th to 31st. As a Participating Organization, Basefarm sent two representatives to the meeting.The big news here was of course the new 3.0 standard, available in draft version at the time. There is currently much focus on the entities that have a low level of PCI awareness, typically small merchants in brick-and-mortar shops. The catchphrase for PCI DSS 3.0 is “Business As Usual”, so much used that it got it’s own TLA; “BAU”. Expect to see the term BAU being used whenever PCI DSS compliance is discussed. It has to be implemented into the daily procedures, which also the “Maintaining Compliance” Special Interest Group has emphasized. In this blog post I will attempt to highlight the most significant changes from the perspective of Basefarm as a hosting provider and how it may affect our customers.

E-commerce requirements

To begin with, the big change discussed at the Community Meeting is how the new e-commerce requirements will actually be implemented. Basically, a lot of web shops managed to avoid the issue of PCI DSS compliance by simply redirecting their customers to the Payment Service Provider at the time of checkout. In 3.0, the definition of PCI DSS Scope (page 6 of the Draft) now defines web redirection servers as systems that may impact the security of the CDE. They are also included in requirement 10.6.1 as part of the system components you have to include in your daily log review. The document “Summary of Changes from PCI DSS Version 2.0 to 3.0 – Draft” does not explicitly mention these changes. Rumours have it that large e-commerce sites must expect to run ASV scans and be prepared to have the payment brands review these. We’ll see what happens, I expect the first reaction of the E-commerce software vendors will be to describe how they have somehow implemented their redirects in a way that leaves them out of scope.

The challenge for PCI DSS hosting providers

As a PCI DSS hosting provider, there has been much focus on third parties during the last year. The “Third Party” Special Interest Group has looked at all kinds of third parties involved and created guidelines. Some of the issues that have been discussed during the creation of the guidelines have been included into the PCI DSS 3.0 standard under 12.8.x instead. One item that will complicate matters for service providers is the new requirement 8.5.1 which says “8.5.1 Service providers with access to customer environments must use a unique authentication credential (such as a password/phrase) for each customer environment.“. The guidance further emphasizes that you cannot use “similar” authentication credentials, such as simply prefixing your password with the customer name. Service providers will have to come up with a solution before the extended time period of June 30th, 2015.

The service provider requirements are clarified with regards to two-factor authentication (8.3) and remote administration (8.1.5) – vendors must be 2FA authenticated and their accounts must be disabled when not in use. The Third Party SIG has also emphasized that the entity required to comply with PCI DSS will retain this responsibility, but all service providers must now be made aware that they are supporting a PCI DSS environment and ensure that they also comply with their relevant requirements (12.8.x). Hopefully, this will ensure that the service providers are professional and knowledgeable in PCI DSS.

In general, the document contains a lot of clarifications and some entirely new items. Here are a few other quick highlights from 3.0:

  • The PCI Council apparently agree with the rest of the world that passwords are dead. There are still specific requirements with regards to password policies and quality, but more importantly they use the more general term “credentials” instead of actual passwords.
  • For the larger merchants, there is a new requirement (9.9) to keep inventory of POS terminals and inspect them for skimming. This has of course to be documented so it can be presented during audit. A necessary update to the standard, but still a time-consuming job. It is one of the requirements that are only best practice until they take effect July 1st 2015.
  • There is a new requirement 2.4 where an inventory of system components must be maintained. If you have cared about any other standards such as ITIL, Cobit, anything ISO or even the SANS Top 20 this is usually high on the list, but has been absent from the PCI requirements. This means it should already be in place for most companies that care about PCI DSS, but it is good to finally see it included in the standard. The PCI justification for the requirement centers around scoping, as asset management has perhaps not been considered an important part of security before. However, you can’t patch what you don’t know you have. Orphaned assets are a known problem in many organisations, where they are only discovered when they are infected with malware and causing network issues.
  • There are some more details on what exactly constitutes a pentest according to the PCI Council, but the main requirement is that you must base the methodology on industry-accepted standards (NIST SP800-115 is mentioned as an example). It is sufficient to demonstrate organizational independence of the tester, there are no approval programs for pentesters (yet). With the focus on pentesting I have seen in previous SIG proposals, I expect this to mature further during future PCI standard versions.
  • In chapter 12, otherwise known as the paperwork requirements, the items that must be included in the security policy have now been relocated from the single 12.1 requirement into each separate requirement. Risk assessments now have to be done not only annually, but after “significant changes to the environment”. And 12.4.1 makes one specific type of separation of duties clearer – security must be handled by an independent role.

All in all, a very useful update to a standard that is maturing and kept up to date. And of course, going to the community meetings create opportunities to meet and chat informally with vendors, colleagues and competitors in a friendly manner. With the usual exchange of war stories about hackers and crazy audit findings.