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.
