How to Implement PCI DSS in a Datacenter as a Third-Party Service Provider?

Introduction:

What is a Third-Party Service Provider?

When planning PCI DSS implementation for a Datacenter, there could be two approaches:

• As Multi-tenant service providers
• As “co-lo” providers

According to PCI DSS v4.0 Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers page 302, there are Multi-tenant service providers - a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases.

Services may include, but are not limited to, hosting multiple entities on a single shared server, providing e-commerce and/or “shopping cart” services, web-based hosting services, payment applications, various cloud applications and services, and connections to payment gateways and processors.

Service providers that provide only shared datacenter services (often called co-location or “co-lo” providers), where equipment, space, and bandwidth are available on a rental basis, are not considered multi-tenant service providers for the purpose of this Appendix.

The implementation process for Multi-tenant service providers we will touch in our next article.

Let us dive in to the process for “co-lo” providers.

Content:

In one of my previous articles, which can be found at this link (https://www.dhirubhai.net/pulse/ready-step-up-begin-your-journey-pci-dss-compliance-kamran-nagiyev-1e), I provided a brief overview of how to initiate a PCI DSS compliance project.

Now, let's delve deeper into the process of implementing PCI DSS compliance specifically for "co-lo" service providers.

1. Scoping

The PCI DSS scope for “co-lo” providers is usually Rack Based Colocation service, where the Datacenter is responsible for physical security, infrastructure and all components used for provision of servers.

All networks going in and out of the rack is considered as public network by the Co-lo tenant/customer. The CDE (CardHolder Data Environment) of the Client resided on the equipment owned/managed by the tenant itself inclusing encryption of in and out trafic.

This approach allows Datacenters to implement PCI DSS only for the segment of the their infrastructure that directly or indirectly related to the provision of the service.

1. Applicability

From the first glance it might be seen that only some limited requirements of PCI DSS are applicable, like Requirement 9 or 12.

But, if to look closer the list of requirements is wider.

Obviously, Requirements 3 and 4 are to be excluded.

But the rest requirements are applicable as below;

Requirement 1: Install and Maintain Network Security Controls

Applicable, for the network segment of the infrastucuture that provides connectivity for in scope sysmtem componets

Requirement 2: Apply Secure Configurations to All System Components

Applicable, for the system components that are in scope. For example, Requirement 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

As per the PCI DSS Glossary -System Component is any network component, server, or application included in or connected to the cardholder data environment.

Requirement 5: Protect All Systems and Networks from Malicious Software

Applicable, for in scope system components to protect from Malicious Software or in simple English this how to setup Anti-malware mechanisms and processes.

Requirement 6: Develop and Maintain Secure Systems and Software

Applicable, although the requirement is mainly about development of custom and bespoke software, there are requirements regarding Vulnerability Management and Change Management.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Requirement 8: Identify Users and Authenticate Access to System Components

Applicable, to setup secure access control model.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Applicable, for in scope system components. No logs not security :)

Requirement 11: Test Security of Systems and Networks Regularly

Applicable, for in scope system components. Any system, even built on the most advances standards, shall be strees tested.

To sum up, the list of applicable Requirements (fully or partially) for 'co-lo' providers:

Requirement 1: Install and Maintain Network Security Controls
Requirement 2: Apply Secure Configurations to All System Components
Requirement 5: Protect All Systems and Networks from Malicious Software
Requirement 6: Develop and Maintain Secure Systems and Software
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Requirement 8: Identify Users and Authenticate Access to System Components	
Requirement 9: Restrict Physical Access to Cardholder Data
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data	
Requirement 11: Test Security of Systems and Networks Regularly
Requirement 12: Support Information Security with Organizational Policies and Programs        

ROC-AOC or SAQ-AOC Approach

"Co-lo" providers are eligible for SAQ D (service providers) and may complete SAQ and AOC (to be done by ISA).

However, to take the ROC-AOC approach e.i. to go for an assessment done by the external Security Assesors (QSAs,) is better approach, since it allows external/different point of view to the processes and systems and add value to the organization. Plus, provide better assurance for Clients during their assessments.

Benefits:

1. Implementation of PCI DSS to a segment of the infrastructure
2. Go approach to start the complaince process; a quick win
3. Ability to demonstrate PCI DSS complaince to a potentail Clients, indicate as Complaince TPSP during the Clients assessment

Conclusion:

If You are, as Datacenter, looking for PCI DSS complaince, this is good approach to go for.