Archive for May 21st, 2010


Passing The Buck

When you are providing services to customers and those services are in-scope for compliance with any of the PCI standards, do not be shocked when your customer’s QSA asks you to prove that you are complying with the relevant PCI standards.  What sort of services are we talking about?  While not a completely inclusive list, here are some of the most common services I run across that are in-scope for PCI compliance.

  • Network management.  This includes management and/or monitoring of firewalls, routers, switches, etc.,
  • Server management.  This includes configuring of servers, patching of servers, add/change/delete of user accounts, monitoring of servers, management of server log files, etc., or
  • Network security management.  This includes management and/or analysis of infrastructure and/or server logs, monitoring of security devices such as firewalls and IDS/IPS, incident response, etc.

The most common point of confusion I run across is with those third parties that are providing network management services.  If the service provider is only providing a telecommunications circuit, then the service provider is not in-scope of PCI compliance.  This fact has been confirmed time and again by the PCI SSC.  However, once you start to be responsible for managing routers, switches or other networking infrastructure, those services are in-scope for PCI compliance.

What I think these service providers forget is that it is not just the storage of cardholder data that is the concern of the PCI standards.  It is the processing and transmission of cardholder data that is also covered.  Now, if cardholder data transmissions are encrypted and the third party does not have the ability to decrypt those transmissions, then the third party is not in-scope.  However, where service providers get in trouble is that the data stream is encrypted at the router that they manage or they manage other devices that come into contact with unencrypted data.  They think that because they are off the hook in one instance, they are off the hook for all which is not the case.

If your company is managing customers’ networks, then explain just how your customers can respond to the following sample of network management compliance tests from the PCI DSS.

  • 1.1.1 – Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations.
  • 1.1.4 – Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.
  • 1.2 – Examine firewall and router configurations to verify that connections are restricted between untrusted networks and system components in the cardholder data environment …
  • 1.2.2 – Verify that router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.

The bottom line is that your customers cannot respond to these requests if your organization is performing them, just ask your customers.  They expect as part of your service agreement to respond to these requests.  Given the ingenuity of entrepreneurs, almost anything can be outsourced for a price, hence why each service that is outsourced needs to be addressed individually to determine whether or not the service is in-scope for PCI compliance.

For those service providers that are reading this and are still unconvinced, I would ask you this question.  If your organization is not responsible, then who is?  Your customer contracted with you to perform the service; therefore they no longer have the knowledge to respond to anything regarding these requests.  If they cannot respond, then who does respond?  And I would point out that if a QSA cannot obtain satisfactory responses to these requirements, then the QSA is obligated to mark them as ‘Not In Place’ which means your customer is not in compliance and must  remediate the problem.

I would remind everyone that security is an all or nothing operation.  Either everyone and everything is secure in the business process chain or they are not secure.  All it takes is just one weak link and the party is over.  We live in a very interconnected world and therefore the security of any one entity can make or break the security of all others.

And if you are still unconvinced, I would have you ask your attorney what happens if a breach occurs at one of your customer’s and is the result of your organization’s failure to comply with one or more of the PCI DSS requirement that caused the breach?  My guess is that your attorney will tell you that you are legally on the hook and that likely all fines, penalties and any other sanctions will be against your organization, not your customer.

And finally, if you are still saying this is all BS, then you better get out of this business because this is what is coming down the line.  QSAs are just the messengers, so do not complain to or about us.  It is the PCI SSC and the card brands that set the rules.  And the PCI SSC is cracking down on QSAs and making sure that we all consistently interpret the PCI DSS and other standards.  So the fact that “no one has asked us about this before” is rapidly coming to an end as every QSA will begin asking for your compliance.

As they like to say, “If it’s too hot in the kitchen, then maybe it’s time to get out.”



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.


May 2010
« Apr   Jun »

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

Join 1,985 other followers