Here is a subject that keeps coming up, particularly with organizations that manage networks for merchants. If I manage an organization’s network, is my organization in-scope for PCI compliance? The answer is yes, the services you are providing are placing your organization and its relevant services in-scope.
The first response from the network management company is usually, “How can that be, all other telecom companies are out of scope, why not us?” Quickly followed by, “No other QSA has ever asked us to go through this.” Remember, the QSA is just the messenger. Everything stated in this post is from the PCI DSS, the DSS Glossary and other PCI SSC and card brand publications. This is what the PCI SSC is asking all QSAs to do as part of their PCI assessment work. If you do not agree, talk to the PCI SSC as they are the only ones that can change the standards.
To answer, “How can that be, all other telecom companies are out of scope, why not us?”
It is very simple. Your organization is not providing just a circuit. The PCI SSC has been very clear on this. If all you are providing is a circuit and no other services, then you are out of scope. The moment your service to a merchant or service provider goes beyond just providing a basic method of transport, you cross into PCI compliance territory. Basically, the PCI SSC’s interpretation is that if the merchant or service provider has outsourced all or part of a role to your organization, it stands to reason that your organization has assumed that responsibility and, by default, also assumed the relevant PCI compliance responsibility.
But, what if the data is encrypted before it gets to our equipment? As long as your organization does not have the ability to decrypt the data stream, then your services are out of scope. However, if the cryptographic process involves your equipment or you manage cryptographic keys, then you are in-scope and must comply with the PCI DSS.
What are your compliance obligations? Based on my analysis, your organization is involved or responsible for at least the following PCI DSS requirements; 1, 2, 4, 6, 7, 8, 9, 10 and 12. Here is my high-level take on what you need to be prepared to document, discuss and/or prove you are doing.
- Provide policies, standards and procedures for device management.
- Provide policies, standards and procedures for physical and logical security.
- Provide a copy of your incident response plan.
- Provide access control definitions for groups and roles that manage the devices.
- Provide job descriptions for the personnel that manage the devices.
- Document all protocols/services that are used for managing the devices including a business reason for each of the protocols/services.
- Provide configurations of a sample of physical devices. Sampling is allowed as long as the service provider can prove that it has implemented a standard process for managing the devices in question.
- Provide documentation that supports that device configurations are properly backed up and secured.
- Provide documentation that supports that device configurations that are running and those that are stored are one in the same.
- Verification that all relevant policies, standards and procedures are followed in configuring new devices.
- Verification that documented protocols/services are the only ones configured on the managed devices.
- Verification that security is properly implemented on all managed devices.
- Verification that appropriate access control systems are implemented on the managed devices.
- Verification that remote access is secure.
- Verification that all user accounts are appropriate managed and controlled.
- Verification that all logging is implemented and logs are reviewed at least daily.
- Verification that log information is properly secured.
- Verification that the time management is properly implemented on each device.
- Verification that some form of critical file monitoring is being performed.
- Verification that there is a formal change management process in place including testing.
- Verification that any cryptographic keys are properly managed and secured.
- Verification that all devices have been appropriately patched and that there is a patch management process in place.
- Verification that appropriate physical security controls are in place.
- Verification that logs are maintained for any backups stored off-site.
- Verification that alerts are responded to as documented in the incident response plan.
Now for the second comment, “No other QSA has ever asked us to go through this.” If no other QSA has asked you to go through this, shame on them. This is why the PCI SSC implemented its Quality Assurance program so that all QSAs start doing the same level of work. This is also why there is such a variance in QSA costs. We are finding that the QSAs that are the cheapest are the ones that are not being appropriately rigorous with their assessment of an organization against the PCI DSS. As the PCI SSC takes more QSAs through the QA process and puts them through remediation, things will change and assessment costs will become more consistent.
PCI Guru 
We are a merchant that uses a PCI compliant software application on our internal network to enter and transmit credit card data via the internet to Authorize.net. The software application has encryption keys and access to the software is controlled through user access unrelated to network user access. We don’t store credit card data.
We want to use a local network service company to manage our network. They will not have user access to the software application and encryption keys but of course will have full network access. They will access our network through third party remote management software.
Based on this I conclude that the network service company does not have to be PCI compliant but the work they do on our network needs to comply with PCI requirements. Further, the remote management software they use to access our network needs to have a secure tunnel with two-factor authentication.
Do you see any fault with these conclusions?
Nothing wrong with your logic. You are absolutely correct in your analysis and what your third party network services provider needs to do.
One thing you did miss is that the network service provider’s personnel need to understand that they could encounter cardholder data (CHD) when on your network and that the CHD needs to be protected, not copied, etc.
Good luck!
PCI Guru, I work for a managed security services company and we are in scope for PCI within a customer’s PCI environment. We offer IDS/IPS and SIEM. From what I understand, the IDS/IPS and the SIEM are both storing the credit card number(full PAN) in the clear. These systems are considered black-boxes and it would be difficult to encrypt the credit card data. How can we de-scope them or become compliant? It seems that we are providing security services to prevent/detect unauthorized use of credit card information, but in turn we are now in scope. This is a “chicken and egg” type scenario. What do you suggest we can do in order to be compliant?
Any help will be greatly appreciated.
Thank you,
I find it hard to believe that your IDS/IPS is storing cardholder data. It may come across it as it is inspecting packets, but it should not be storing it in the sense of an application would store it. I am guessing that the IDS/IPS is being brought into in-scope because it is behind an SSL/TLS endpoint so that traffic to e-Commerce sites can be inspected. Typically, the only time cardholder data would be recorded by an IDS/IPS would be if there is something wrong with the packet and then it would end up in log data which brings your SIEM into the picture – more on that in a minute. I would say as long as you can show that the IDS/IPS log data that contains cardholder data is immediately transferred to the SIEM and cannot be accessed in the IDS/IPS log, then the IDS/IPS will be compliant.
That brings us to how to secure your SIEM. Most SIEM solutions get their security by encrypting the data store used by the SIEM and restricting access to the data store to only the SIEM application. Windows EFS can do this through an EFS encrypted folder that contains the data store. Symantec PGP has a similar solution. The key is to not allow backup processes or administrators other than the SIEM support staff to have access to the folder unencrypted. Anyone other than those limited to SIEM administrators can only access the SIEM data through the SIEM application.
Good Afternoon –
We are a Managed IT Services Provider that has been recently commissioned to assess a Company’s current PCI compliance. We have been sifting throught TONS of Data, but still unclear on one major topic – Backups. The Client currently uses Backup Exec and it is configured to backup the CDE along with the Non-CDE data. Is this in compliance, or should this be changed? The Data is not being replicated offsite, but we are still not sure if the two types of data can coexist on the same backup media.
Thanks!
Guys, please advise.
Our hosting services provider is a reseller from huge datacenter. Datacenter itself has PCI DSS certificate, but our reseller doesn’t. How is this situation compliant with PCI DSS, what documents should we get from datacenter and reseller to make our QSA happy?
Thanks.
Your service provider is only a sales organization, not the actual entity providing your services. They likely do not come into contact with your cardholder data, but you should confirm this fact. As long as the entity providing your services that do come in contact with your cardholder data are PCI compliant, you should be fine.
So…I can outsource all my IT (and beyond) functions that might fall into PCI, and then dance around happily while saying, “I don’t manage those functions, therefore I’m not a merchant, and because of contract law I also can’t pass that obligation on to those people who manage my IT?”
Even though you outsource everything, you are still the merchant of record because your company signed the merchant agreement with the acquiring bank. So while your outsourcing reduces your PCI compliance requirements, you are still on the hook if any of your outsourcers ever drop the ball because it is your responsibility to make sure that they keep up their contractual requirements and are PCI compliant. Essentially, your acquiring bank will sue you and you will sue the respective outsourcers. Isn’t the law fun? LOL
This is a typical case of PCI IN scope creep ( and many QSAs and consultants are directly responsible for this illegal scope creep) and contract law as it exist to day DO NOT permit it.
A contract between A & B can not bind C, D & E who do business with B.
Any interpretation that is counter to it will strike at the very foundation of the founding principles of contract law( http://www.scribd.com/doc/2441357/General-Principles-of-Law-of-Contract?secret_password=&autodown=doc) and no court will provide relief if B, C or D refuse to honor a non-existent contract!
The very minimum that are required is:
1. Proposal
2. Acceptance
3. Promise
4. Agreement
and all the above constitute an enforceable contract! Any one item missing make it unenforceable.
PCI Council can say any thing they feel like in the matter. If there is no enforceable contract, no amount puffing can create one. Puffing presents opinions rather than facts and is usually not considered a legally binding promise
Don’t throw your QSA under the bus, we’re just the messenger. It’s the PCI SSC and the card brands that are in control.
However, that said, how do you figure that a service provider with access to cardholder data gets to skate Scot-free and the merchant or service provider have to tow the line? Security is an all or nothing thing and is only as good as its weakest link. If the telcom provider can do whatever they want and end up being the breach point, don’t you think people would be pretty PO’d by your narrow view of how to security cardholder data?
Regardless, PCI DSS requirement 12.8.2 states that ” … the written agreement includes an acknowledgment by the service providers of their responsibility for securing cardholder data.” If you want to get around that, stop taking credit cards for payment. Under your merchant or service provider agreement (i.e., a legally binding contract) with your acquiring bank you MUST abide by the PCI standards or they will revoke your ability to process credit cards.
Just to make sure we’re all on the same page, a service provider is defined by the PCI DSS Glossary as “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.” The problem is that once a telcom provider starts managing routers, firewalls, switches, etc. they are now in-scope because they are no longer just providing a communication link, they have access to the application layer.
Service providers can either suffer through a PCI assessment with each of its customers that place it in-scope OR they can perform their own PCI assessment of all of their in-scope services and provide their customers with a copy of their Attestation Of Compliance (AOC) or a letter signed by an officer of the service provider stating that they comply with all relevant PCI standards.
It looks as if every one is making a mistake here.
PCI DSS is a standard imposed due to contractual requirements between the Merchant and the Acquiring Bank PERIOD.
The standard is not a regulatory compliance(though this is changing as some states are leaning to PCI DSS as mandatory compliance to the parties. That apart..)
Any one who does business with a Merchant does NOT come with in scope of PCI DSS. The customer merchant can impose the standard on their service provider. If the service provider does not meet the standard, he might lose this business. That is NOT same as service provider “coming within SCOPE” of PCI DSS.
This is a contractual requirement to be interpreted strictly on the basis of law of contracts and QSA is unqualified to interpret it and bring the network provider “within SCOPE OF PCI DSS” what ever that means!
Chandra
The problem is that the merchant and service provider agreements that I have seen state that the merchant/service provider and all of its relevant third parities are required to be PCI compliant. Plus, the PCI DSS requires that the merchant/service provider put those third parties on the legal hook as well. As a result, the third party is contractually brought into the equation by one or the other. However, a lawyer would need to review all documents to give us a true legal opinion as to whether or not that can be enforced.