Quick Hits From PCI Dream Team Session 10

The following are some questions that were asked at the last PCI Dream Team session but we were unable to get to them during the session.

1. If a PCI validated service provider omits requirements from SAQ-D-SP because they themselves also use PCI Validated Service providers who meet said requirements?
   
   First off, requirements cannot be “omitted” or marked “Not Tested” and have a compliant Service Provider SAQ D or ROC per FAQ #1382.
   As to how the organization should deal with requirements covered by a third party is to mark them as “In Place” with the description that the appropriate third party is responsible for the requirement and that the third party is PCI compliant as of the AOC date.
   
2. Most QSA’s are suggesting that the best way to mitigate new requirements in PCI V4 is to implement P2PE. Would you agree?
   
   Going to a P2PE or E2EE solution is only part of the equation.  To reduce the scope the most, you would also want to implement tokenization to ensure that your systems never retain PAN.  It is important to remember that most P2PE/E2EE solutions do not automatically include tokenization.
   Also remember, only P2PE gets the immediate scope reduction without asking the acquiring bank.  However, E2EE can also result in scope reduction if properly documented and approved by your acquiring bank, so do not limit yourself to only P2PE solutions.  E2EE solutions from First Data (TransArmor) and Verifone (VeriShield) are the largest implemented scope reducing solutions in the marketplace and are offered through almost all payment processors.
   
3. Can you give examples of connected-to tools for pushing out code – are you referring to Git, Chef, what other tools fall into this category?
   
   Yes, we were talking about tools such as Git, Jenkins and Chef.  But it is also more than just code that gets pushed out.  Configurations, networking, etc. are all getting pushed out by tools such as Ansible, Terraform and others in the cloud and are also in scope.
   Regardless of the PCI scoping issues, these tools create security issues for organizations because they are typically not very well protected and monitored.  These tools are an organization’s software factory and most organizations are leaving the factory’s doors wide open for anyone to come through and see how you construct your in-house software solutions that are supposedly the key to your organization’s success.  All of this should hit home pretty hard after the SolarWinds debacle.
   
4. On the topic of end of life (EOL) software, what about open-source projects with no LTS such as React 16 since the next major version has been released?  Would I be compelled to update all my dependencies to the latest major version?
   
   As far as I am aware, there is no announced React 16 EOL date nor has there ever been an EOL announcement for any release of React.  That said, since React is a group of JavaScript libraries and JavaScript is a well-known attack vector, the risk of using an older React version just gets worse as time goes on.  A risk assessment for the React versions should take that all into account and drive your analysis as to when you should update React barring the vendor stating an EOL for the version.
   But there are larger issues with open source application projects that process, store or transmit cardholder data (CHD).  I wrote about this a few years back in this post and it has a link to a post on the subject from 10 years ago.

Advertisement